Re: [edk2] [patch] MdeModulePkg:Fix a bug that HttpLib can not parse Ipv6 address correctly.
The patch looks good to me.
Reviewed-by: Wu Jiaxin
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang
Lubo
Sent: Friday, November 6, 2015 4:12 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin; Gary Ching-Pang Lin
Subject: [edk2] [patch] MdeModulePkg:Fix a bug that HttpLib can not parse Ipv6
address correctly.
v2:
*Add a Url Parse state machine to indicate the host is ipv6 expressed url and
can parse the ipv6 address correctly.
Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin
CC: Gary Ching-Pang Lin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 33
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
index aeb52d0..500b3c7 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
@@ -68,10 +68,11 @@ typedef enum {
UrlParserFragmentStart, // "#"
UrlParserFragment,
UrlParserUserInfo,
UrlParserHostStart, // "@"
UrlParserHost,
+ UrlParserHostIpv6, // "["(Ipv6 address) "]"
UrlParserPortStart, // ":"
UrlParserPort,
UrlParserStateMax
} HTTP_URL_PARSE_STATE;
@@ -136,17 +137,20 @@ UriPercentDecode (
This function return the updated state accroding to the input state and next
character of
the authority.
@param[in] Char Next character.
@param[in] State Current value of the parser state machine.
+ @param[in] IsRightBracket TRUE if there is an sign ']' in the
authority component and
+ indicates the next part is ':' before Port.
@return Updated state value.
**/
HTTP_URL_PARSE_STATE
NetHttpParseAuthorityChar (
IN CHAR8 Char,
- IN HTTP_URL_PARSE_STATE State
+ IN HTTP_URL_PARSE_STATE State,
+ IN BOOLEAN*IsRightBracket
)
{
//
// RFC 3986:
@@ -167,16 +171,31 @@ NetHttpParseAuthorityChar (
return UrlParserHostStart;
}
break;
case UrlParserHost:
- case UrlParserHostStart:
+ case UrlParserHostStart:
+if (Char == '[') {
+ return UrlParserHostIpv6;
+}
+
if (Char == ':') {
return UrlParserPortStart;
}
+
return UrlParserHost;
-
+
+ case UrlParserHostIpv6:
+if (Char == ']') {
+ *IsRightBracket = TRUE;
+}
+
+if (Char == ':' && *IsRightBracket == TRUE) {
+ return UrlParserPortStart;
+}
+return UrlParserHostIpv6;
+
case UrlParserPort:
case UrlParserPortStart:
return UrlParserPort;
default:
@@ -208,10 +227,11 @@ NetHttpParseAuthority (
CHAR8 *Authority;
UINT32Length;
HTTP_URL_PARSE_STATE State;
UINT32Field;
UINT32OldField;
+ BOOLEAN IsrightBracket;
ASSERT ((UrlParser->FieldBitMap & BIT (HTTP_URI_FIELD_AUTHORITY)) != 0);
//
// authority = [ userinfo "@" ] host [ ":" port ]
@@ -220,16 +240,17 @@ NetHttpParseAuthority (
State = UrlParserUserInfo;
} else {
State = UrlParserHost;
}
+ IsrightBracket = FALSE;
Field = HTTP_URI_FIELD_MAX;
OldField = Field;
Authority = Url + UrlParser->FieldData[HTTP_URI_FIELD_AUTHORITY].Offset;
Length = UrlParser->FieldData[HTTP_URI_FIELD_AUTHORITY].Length;
for (Char = Authority; Char < Authority + Length; Char++) {
-State = NetHttpParseAuthorityChar (*Char, State);
+State = NetHttpParseAuthorityChar (*Char, State, &IsrightBracket);
switch (State) {
case UrlParserStateMax:
return EFI_INVALID_PARAMETER;
case UrlParserHostStart:
@@ -241,10 +262,14 @@ NetHttpParseAuthority (
break;
case UrlParserHost:
Field = HTTP_URI_FIELD_HOST;
break;
+
+case UrlParserHostIpv6:
+ Field = HTTP_URI_FIELD_HOST;
+ break;
case UrlParserPort:
Field = HTTP_URI_FIELD_PORT;
break;
--
1.9.5.msysgit.1
___
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] [patch] NetworkPkg:Fix the issue that cannot parse ipv6 address correctly.
Reviewed-by: Wu Jiaxin
-Original Message-
From: Zhang, Lubo
Sent: Monday, November 9, 2015 1:26 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan; Ye, Ting; Wu, Jiaxin; Gary Ching-Pang Lin
Subject: [patch] NetworkPkg:Fix the issue that cannot parse ipv6 address
correctly.
If there is a ipv6 expressed url, the NetLibAsciiStrToIp6 cannot get the Ipv6
address from the host name, because the host name contains left and right
bracket which cannot be used to configure the Tcp6 connection.
Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin
CC: Gary Ching-Pang Lin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
NetworkPkg/HttpDxe/HttpImpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index c527da0..2f4ce89 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -388,11 +388,11 @@ EfiHttpRequest (
// Parse Url for IPv4 or IPv6 address, if failed, perform DNS resolution.
//
if (!HttpInstance->LocalAddressIsIPv6) {
Status = NetLibAsciiStrToIp4 (HostName, &HttpInstance->RemoteAddr);
} else {
- Status = NetLibAsciiStrToIp6 (HostName, &HttpInstance->RemoteIpv6Addr);
+ Status = HttpUrlGetIp6 (Url, UrlParser,
+ &HttpInstance->RemoteIpv6Addr);
}
if (EFI_ERROR (Status)) {
HostNameStr = AllocateZeroPool ((AsciiStrLen (HostName) + 1) * sizeof
(CHAR16));
if (HostNameStr == 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] ShellPkg: Network commands (ifconfig/ping) broken
Hi Laszlo and Conen, Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg in UDK2015 release version, Both of them have included my patch for Ip4Config Protocol deprecated work. I'm also confused by the test result below, seems only time appeared abnormal. Conen: Are you using the shell binary released in UDK2015? Thanks. Jiaxin -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, November 10, 2015 4:30 AM To: Conen, Johannes; edk2-devel@lists.01.org Cc: Leif Lindholm (Linaro address); Wu, Jiaxin Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken On 11/09/15 16:52, Conen, Johannes wrote: > Hello everyone, > > after switching from UDK2014 to UDK2015, I noticed that the network > commands (ifconfig / ping) don't work anymore. ifconfig just exits > with no feedback and ping says "Config no mapping" (logical, as it is > not possible to get an IP address via ifconfig). In UDK2014 everything > worked fine. > > With the help of unixsmurf (thanks a lot) Argh. Can we stop using these "funny" nicks on IRC? "unixsmurf" is Leif. What do you think, Leif? :) > I went on bughunting and > found out that commit r17869 / git sha > 7c25b7ea5b2c029a9e7a0be57f7c20f31d720c7d broke it. Wild guess: it has > something to do with the new protocol. That's close, but my take is not that exact commit. Instead, what about this: https://github.com/tianocore/edk2/commit/2aa0eb5df61e == SVN rev 17917. (I reviewed that commit.) But, it works for me: > Shell> ifconfig -s eth0 dhcp > Shell> ifconfig -l eth0 > > - > > name : eth0 > Media State : Media present > policy : dhcp > mac addr : 52:54:00:29:80:AE > > ipv4 address : 192.168.122.182 > > subnet mask : 255.255.255.0 > > default gateway: 192.168.122.1 > > Routes (2 entries): > Entry[0] > Subnet : 192.168.122.0 > Netmask: 255.255.255.0 > Gateway: 0.0.0.0 > Entry[1] > Subnet : 0.0.0.0 > Netmask: 0.0.0.0 > Gateway: 192.168.122.1 > > DNS server : > 192.168.122.1 > > > - > Shell> ping 8.8.8.8 > Ping 8.8.8.8 16 data bytes. > 16 bytes from 8.8.8.8 : icmp_seq=1 ttl=0 time=30640ms > 16 bytes from 8.8.8.8 : icmp_seq=2 ttl=0 time=31249ms > 16 bytes from 8.8.8.8 : icmp_seq=3 ttl=0 time=33280ms > 16 bytes from 8.8.8.8 : icmp_seq=4 ttl=0 time=38577ms > 16 bytes from 8.8.8.8 : icmp_seq=5 ttl=0 time=28432ms > 16 bytes from 8.8.8.8 : icmp_seq=6 ttl=0 time=31275ms > 16 bytes from 8.8.8.8 : icmp_seq=7 ttl=0 time=26576ms > 16 bytes from 8.8.8.8 : icmp_seq=8 ttl=0 time=33192ms > 16 bytes from 8.8.8.8 : icmp_seq=9 ttl=0 time=31112ms > 16 bytes from 8.8.8.8 : icmp_seq=10 ttl=0 time=28237ms > > 10 packets transmitted, 10 received, 0% packet loss, time 312570ms > > Rtt(round trip time) min=26576ms max=38577ms avg=31257ms This on OVMF just built from edk2 at SVN rev18759. (Note that in OVMF the shell is built from source as well.) > Personally I think this is a critical issue - it practically makes it > impossible to use any network related stuff in the UEFI shell. I suspect that you are using an old (UDK2014) shell binary on top of a new (UDK2015) network stack, or vice-versa. If you check the commit message of SVN rev 17917 / git 2aa0eb5df61e, it said that it was safe to remove the Ip4Config protocol *because* SVN rev 17869 / git 7c25b7e [that you have found] had already moved ping / ifconfig to the new protocol. And at the time of SVN rev 17869 / git 7c25b7e, the new protocol existed (see SVN rev 17853 / git 1f6729ffe980). In chronological order: - SVN rev 17853 / git 1f6729ff: implements the Ip4Config2 protocol, - SVN rev 17869 / git 7c25b7ea: migrates ping & ifconfig to Ip4Config2, - SVN rev 17917 / git 2aa0eb5d: removes Ip4Config (no more users) So, assuming you build *all* of your firmware from edk2, from source, including the shell, you should end up with working ping & ifconfig at any stage. I don't know at what stage UDK2015 was packaged. If it happened after SVN rev 17917 / git 2aa0eb5d, then I guess the message of that commit applies: "Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol" -- please use a conformant shell I guess. I'm still a bit confused, because ShellBinPkg was also updated in SVN rev 18187 / git 1fe76acc, which was about a month after SVN rev 17917 / git 2aa0eb5d above. So unless Intel released UDK2015 exactly within that one month, I cannot see how you can encounter this problem. Are you using a shell binary whose source is still based on UDK2014 (or older)? Thanks, Laszlo > With best regards, > Johannes Conen >
Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
Yes, Laszlo, we have discussed this topic for a long time, and also we have declared that dependent network drivers, libraries and applications have been migrated to the new protocol version. But no one have more comments for that compatibility change. Since UEFI2.5 Spec also declares the EFI_IP4_CONFIG_PROTOCOL has been replaced with the new EFI_IP4_CONFIG2_PROTOCOL, we think it's ok to deprecate the old protocol. Thanks. Jiaxin -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, November 10, 2015 7:54 PM To: Leif Lindholm Cc: Wu, Jiaxin; edk2-devel@lists.01.org Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken On 11/10/15 11:43, Leif Lindholm wrote: > On Tue, Nov 10, 2015 at 11:28:10AM +0100, Laszlo Ersek wrote: >> On 11/10/15 11:20, Conen, Johannes wrote: >>> Hmm, you're right. is it briefly mentioned in the "ShellPkg >>> Notes.txt" - I must admit, I only took a look at the >>> "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major >>> changes to mentioned there (and well, they were, like the moving of >>> the library files). So this non-backwards-compatibility from UDK2015 >>> to >>> UDK2014 regarding network-related stuff is intended? >> >> I'll have to let Jiaxin answer this question; I'm not a participant >> in UDK feature planning. And, I have no idea how UDK releases account >> for compatibility in general. >> >> (My *guess* is that UDK2015 generally targets (or moved towards) UEFI >> 2.5, and Ip4Config (version 1) is apparently deprecated in UEFI 2.5.) > > The actual wording from the specification is: > --- > The EFI_IP4_CONFIG_PROTOCOL has been replaced with the new > EFI_IP4_CONFIG2_PROTOCOL. > . All new designs based on this specification should exclusively use > EFI_IP4_CONFIG2_PROTOCOL . > . The EFI_IP4_CONFIG_PROTOCOL will be removed in the next revision of > this specification. > --- > > Clearly this creates a compatibility breakage at some point. > > Is this something we consider "not a problem", or should the shell > implement (providing a reference for how to implement) fallback to > EFI_IP4_CONFIG_PROTOCOL if EFI_IP4_CONFIG2_PROTOCOL is not available? Whether the shell in edk2 should or should not provide fallback code for EFI_IP4_CONFIG_PROTOCOL is for Intel to answer :), but I think I can ask one more question as to "how". Namely, if one adds (or keeps) the Ip4Config fallback code to (in) the shell in edk2, how does that compat feature get tested, staying within the tree? It would require keeping the Ip4Config protocol implementation around just for the sake of testing the fallback. I don't think that's a good idea. Instead, any dependencies on specific versions of the UEFI spec should be spelled out loud and clear. (I believe I've read such requirements presented by Windows, on MSDN.) Mapping each UDK release to a UEFI spec version would be a bonus. Thanks Laszlo > > Regards, > > Leif > >> Thanks >> Laszlo >> >>> >>> Greetings >>> Johannes >>> >>> -Ursprüngliche Nachricht- >>> Von: Laszlo Ersek [mailto:ler...@redhat.com] >>> Gesendet: Dienstag, 10. November 2015 11:06 >>> An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org >>> Cc: Leif Lindholm (Linaro address) >>> Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) >>> broken >>> >>> On 11/10/15 10:49, Conen, Johannes wrote: >>>> Hi there, >>>> >>>> I made my tests with the binary shell from ShellBinPkg from >>>> UDK2014, from UDK2015, the current master and a few commits in >>>> between and rebuilt the shell from ShellPkg for UDK2014, UDK2015, >>>> the current master and a few commits in between UDK2014 and UDK2015. >>>> >>>> It worked fine with r17868 and didn't work anymore with r17869, so >>>> it has to be that commit (I of course rebuilt the shell from ShellPkg). >>>> If I put both shells on a USB-stick and switch between them on the >>>> fly, it works in the one built from r17868 and doesn't work in the >>>> one built from r17869. Regarding ShellBinPkg: the last version that >>>> worked is r17619 (which is quite logical since the version after >>>> that, r18187, is built from ShellPkg r18186, which didn't work for >>>> me anymore). >>>> >>>> I'm not working on OVMF, but on real hardware (X64) - don't know >>>> exactly with which version the UEFI f
Re: [edk2] [patch] NetworkPkg: Report Http Errors to screen when http layer occurs an error
Reviewed-by: Wu Jiaxin
-Original Message-
From: Zhang, Lubo
Sent: Monday, November 9, 2015 5:57 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin; Samer El-Haj-Mahmoud
Subject: [patch] NetworkPkg: Report Http Errors to screen when http layer
occurs an error
v2:
* Change the print message to a more readable string and add the redirection
status code
(3xx)
Cc: Ye Ting
Cc: Fu Siyuan
CC: Wu Jiaxin
CC: Samer El-Haj-Mahmoud
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
NetworkPkg/HttpBootDxe/HttpBootSupport.c | 151 ++-
1 file changed, 150 insertions(+), 1 deletion(-)
diff --git a/NetworkPkg/HttpBootDxe/HttpBootSupport.c
b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
index d08111f..1fc4e76 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootSupport.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootSupport.c
@@ -145,10 +145,153 @@ HttpBootShowIp6Addr (
}
}
}
/**
+ This function is to display the HTTP error status.
+
+ @param[in] StatusCode The status code value in HTTP message.
+
+**/
+VOID
+HttpBootPrintErrorMessage (
+ EFI_HTTP_STATUS_CODEStatusCode
+ )
+{
+ AsciiPrint ("\n");
+
+ switch (StatusCode) {
+ case HTTP_STATUS_300_MULTIPLE_CHIOCES:
+AsciiPrint ("\n Redirection: 300 Multiple Choices");
+break;
+
+ case HTTP_STATUS_301_MOVED_PERMANENTLY:
+AsciiPrint ("\n Redirection: 301 Moved Permanently");
+break;
+
+ case HTTP_STATUS_302_FOUND:
+AsciiPrint ("\n Redirection: 302 Found");
+break;
+
+ case HTTP_STATUS_303_SEE_OTHER:
+AsciiPrint ("\n Redirection: 303 See Other");
+break;
+
+ case HTTP_STATUS_304_NOT_MODIFIED:
+AsciiPrint ("\n Redirection: 304 Not Modified");
+break;
+
+ case HTTP_STATUS_305_USE_PROXY:
+AsciiPrint ("\n Redirection: 305 Use Proxy");
+break;
+
+ case HTTP_STATUS_307_TEMPORARY_REDIRECT:
+AsciiPrint ("\n Redirection: 307 Temporary Redirect");
+break;
+
+ case HTTP_STATUS_400_BAD_REQUEST:
+AsciiPrint ("\n Client Error: 400 Bad Request");
+break;
+
+ case HTTP_STATUS_401_UNAUTHORIZED:
+AsciiPrint ("\n Client Error: 401 Unauthorized");
+break;
+
+ case HTTP_STATUS_402_PAYMENT_REQUIRED:
+AsciiPrint ("\n Client Error: 402 Payment Required");
+break;
+
+ case HTTP_STATUS_403_FORBIDDEN:
+AsciiPrint ("\n Client Error: 403 Forbidden");
+break;
+
+ case HTTP_STATUS_404_NOT_FOUND:
+AsciiPrint ("\n Client Error: 404 Not Found");
+break;
+
+ case HTTP_STATUS_405_METHOD_NOT_ALLOWED:
+AsciiPrint ("\n Client Error: 405 Method Not Allowed");
+break;
+
+ case HTTP_STATUS_406_NOT_ACCEPTABLE:
+AsciiPrint ("\n Client Error: 406 Not Acceptable");
+break;
+
+ case HTTP_STATUS_407_PROXY_AUTHENTICATION_REQUIRED:
+AsciiPrint ("\n Client Error: 407 Proxy Authentication Required");
+break;
+
+ case HTTP_STATUS_408_REQUEST_TIME_OUT:
+AsciiPrint ("\n Client Error: 408 Request Timeout");
+break;
+
+ case HTTP_STATUS_409_CONFLICT:
+AsciiPrint ("\n Client Error: 409 Conflict");
+break;
+
+ case HTTP_STATUS_410_GONE:
+AsciiPrint ("\n Client Error: 410 Gone");
+break;
+
+ case HTTP_STATUS_411_LENGTH_REQUIRED:
+AsciiPrint ("\n Client Error: 411 Length Required");
+break;
+
+ case HTTP_STATUS_412_PRECONDITION_FAILED:
+AsciiPrint ("\n Client Error: 412 Precondition Failed");
+break;
+
+ case HTTP_STATUS_413_REQUEST_ENTITY_TOO_LARGE:
+AsciiPrint ("\n Client Error: 413 Request Entity Too Large");
+break;
+
+ case HTTP_STATUS_414_REQUEST_URI_TOO_LARGE:
+AsciiPrint ("\n Client Error: 414 Request URI Too Long");
+break;
+
+ case HTTP_STATUS_415_UNSUPPORTED_MEDIA_TYPE:
+AsciiPrint ("\n Client Error: 415 Unsupported Media Type");
+break;
+
+ case HTTP_STATUS_416_REQUESTED_RANGE_NOT_SATISFIED:
+AsciiPrint ("\n Client Error: 416 Requested Range Not Satisfiable");
+break;
+
+ case HTTP_STATUS_417_EXPECTATION_FAILED:
+AsciiPrint ("\n Client Error: 417 Expectation Failed");
+break;
+
+ case HTTP_STATUS_500_INTERNAL_SERVER_ERROR:
+AsciiPrint ("\n Server Error: 500 Internal Server Error");
+break;
+
+ case HTTP_STATUS_501_NOT_IMPLEMENTED:
+AsciiPrint ("\n Server Error: 501 Not Implemented");
+break;
+
+ case HTTP_STATUS_502_BAD_GATEWAY:
+AsciiPrint ("\n Server Error: 502 Bad Gateway");
+break;
+
+ case HTTP_STATUS_503_SERVICE_UNAVAILABLE:
+AsciiPrint ("\n Server Error: 503 Service Unavailable");
+break;
+
+ case HTTP_STATUS_504_GATEWAY_TIME_OUT:
+AsciiPrint ("\n Server Error: 504 Gateway Timeout");
Re: [edk2] Ip4Config to Ip4Config2 Transition
Hi Eugene, Yes, the setting data will be stored in the NV variable named by the every NIC's MacString. The driver try to read those config data from NV variable when it started. You don't lose your configuration data after you do some manual setting. Thanks. Jiaxin From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Friday, November 20, 2015 1:38 AM To: edk2-devel@lists.01.org; Wu, Jiaxin Subject: Ip4Config to Ip4Config2 Transition Jiaxin Wu, I'm updating edk2 to a new version that includes the removal of legacy Ip4Config and addition of the new Ip4Config2 protocol. I'm wondering what this does to network settings already stored in NVRAM? Does the data get lost or will the new driver preserve the existing settings? Thanks, Eugene The commit was this: Revision: 2aa0eb5df61eceebf9aa47cd9b90f2a39ee87fe7 Author: Jiaxin Wu mailto:jiaxin...@intel.com>> Date: 7/9/2015 11:49:48 PM Message: MdeModulePkg: Remove Ip4ConfigDxe and related guid definition Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol, which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)). Dependent network drivers, libraries and applications have been migrated to (or extended to) the new protocol version. For example: git 7c25b7ea (SVN r17869): ping & ifconfig git 00a6ad1b (SVN r17870): UefiHandleParsingLib git 6c5c70d6 (SVN r17873): DxeNetLib git 39561686 (SVN r17874): IpSecDxe git c581e503 (SVN r17875): EfiSocketLib This patch is based on related packages(MdeModulePkg, Nt32Pkg, ArmPlatformPkg, ArmVirtPkg, EmulatorPkg, OvmfPkg, Vlv2TbltDevicePkg) clean-up work finished. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu mailto:jiaxin...@intel.com>> Reviewed-by: Laszlo Ersek mailto:ler...@redhat.com>> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17917 6f19259b-4bc3-4df7-8a09-765794883524 Deleted: MdeModulePkg/Include/Guid/Ip4ConfigHii.h Deleted: MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h Modified: MdeModulePkg/MdeModulePkg.dec Modified: MdeModulePkg/MdeModulePkg.dsc Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/ComponentName.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.h Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDriver.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.uni Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4NvData.h Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.h ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Ip4Config to Ip4Config2 Transition
Thanks Ting's clarification. -Original Message- From: Ye, Ting Sent: Friday, November 20, 2015 11:07 AM To: Wu, Jiaxin; Cohen, Eugene; edk2-devel@lists.01.org Subject: RE: Ip4Config to Ip4Config2 Transition Hi Eugene, Are you asking whether the new driver producing Ip4Config2 protocol can support the previous network setting configured by old driver producing Ip4Config protocol in NVRAM? If yes, I think the answer is no. I think what Jiaxin says is that the new driver will save the configuration in NVRAM and won't lost the data across system reset. Just want to make sure we don't misunderstand each other. Thanks, Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wu, Jiaxin Sent: Friday, November 20, 2015 9:14 AM To: Cohen, Eugene; edk2-devel@lists.01.org Subject: Re: [edk2] Ip4Config to Ip4Config2 Transition Hi Eugene, Yes, the setting data will be stored in the NV variable named by the every NIC's MacString. The driver try to read those config data from NV variable when it started. You don't lose your configuration data after you do some manual setting. Thanks. Jiaxin From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Friday, November 20, 2015 1:38 AM To: edk2-devel@lists.01.org; Wu, Jiaxin Subject: Ip4Config to Ip4Config2 Transition Jiaxin Wu, I'm updating edk2 to a new version that includes the removal of legacy Ip4Config and addition of the new Ip4Config2 protocol. I'm wondering what this does to network settings already stored in NVRAM? Does the data get lost or will the new driver preserve the existing settings? Thanks, Eugene The commit was this: Revision: 2aa0eb5df61eceebf9aa47cd9b90f2a39ee87fe7 Author: Jiaxin Wu mailto:jiaxin...@intel.com>> Date: 7/9/2015 11:49:48 PM Message: MdeModulePkg: Remove Ip4ConfigDxe and related guid definition Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol, which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)). Dependent network drivers, libraries and applications have been migrated to (or extended to) the new protocol version. For example: git 7c25b7ea (SVN r17869): ping & ifconfig git 00a6ad1b (SVN r17870): UefiHandleParsingLib git 6c5c70d6 (SVN r17873): DxeNetLib git 39561686 (SVN r17874): IpSecDxe git c581e503 (SVN r17875): EfiSocketLib This patch is based on related packages(MdeModulePkg, Nt32Pkg, ArmPlatformPkg, ArmVirtPkg, EmulatorPkg, OvmfPkg, Vlv2TbltDevicePkg) clean-up work finished. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu mailto:jiaxin...@intel.com>> Reviewed-by: Laszlo Ersek mailto:ler...@redhat.com>> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17917 6f19259b-4bc3-4df7-8a09-765794883524 Deleted: MdeModulePkg/Include/Guid/Ip4ConfigHii.h Deleted: MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h Modified: MdeModulePkg/MdeModulePkg.dec Modified: MdeModulePkg/MdeModulePkg.dsc Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/ComponentName.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4Config.h Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDriver.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.uni Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.vfr Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeExtra.uni Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxeStrings.uni Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigNv.h Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4NvData.h Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.c Deleted: MdeModulePkg/Universal/Network/Ip4ConfigDxe/NicIp4Variable.h ___ 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] [PATCH] ShellPkg: Wrong return status for Ifconfig.c
Jaben,
Is there any generic EFI-to-Shell status conversion routine/macro? If no, as
Eugene has declared the below patch is a temporary patch and can't give the
useful returned status, a formal patch is required to fix this issue.
Thanks.
Jiaxin
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen,
Eugene
Sent: Tuesday, November 24, 2015 10:38 PM
To: edk2-devel@lists.01.org; Carsey, Jaben
Subject: [edk2] [PATCH] ShellPkg: Wrong return status for Ifconfig.c
The Ifconfig command handler tries to return an EFI_STATUS when the return type
should be SHELL_STATUS. RVCT 4 is (correctly) flagging this as an error:
edk2\ShellPkg\Library\UefiShellNetwork1CommandsLib\Ifconfig.c(1387,10): error
#188-D: enumerated type mixed with another type
I haven't found a pattern to convert EFI_STATUS to SHELL_STATUS that works well
- the examples I've seen seem to lump all EFI_STATUS errors into a single shell
error like "if(EFI_ERROR(Status)) ShellStatus = SHELL_INVALID_PARAMETER"
resulting in loss of useful information. I was hoping there would be a generic
EFI-to-Shell status conversion routine/macro that could help do this.
Here's a crummy temporary patch to convert the return status.
--
f281fca920f1bb33b2c15cb498a8889bbe9ff035
edk2/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/edk2/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
b/edk2/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
index e16d46a..609c535 100644
--- a/edk2/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
+++ b/edk2/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
@@ -1384,5 +1384,9 @@ ON_EXIT:
IfConfigCleanup (Private);
}
- return Status;
+ if (EFI_ERROR(Status)) {
+return SHELL_ABORTED;
+ } else {
+return SHELL_SUCCESS;
+ }
}
--
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen < eug...@hp.com>
Eugene
___
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] [PATCH v2] NetworkPkg:Fix NULL pointer dereference issues.
Looks good.
Reviewed-by: Wu Jiaxin
-Original Message-
From: Zhang, Lubo
Sent: Thursday, November 26, 2015 10:19 AM
To: Fu, Siyuan; edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin; Qiu, Shumin
Subject: RE: [edk2] [PATCH v2] NetworkPkg:Fix NULL pointer dereference issues.
Yes, the HttpHeaders always not be a NULL pointer when a success call from
HttpTcpReceiveHeader function, I will modify when I commit.
Thanks
-Original Message-
From: Fu, Siyuan
Sent: Thursday, November 26, 2015 10:09 AM
To: Zhang, Lubo; edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin; Qiu, Shumin
Subject: RE: [edk2] [PATCH v2] NetworkPkg:Fix NULL pointer dereference issues.
Hi, Lubo
Should HttpHeaders always not be a NULL pointer upon a success call of
HttpTcpReceiveHeader?
If yes, you should use ASSERT here, otherwise the patch is ok with me?
Status = HttpTcpReceiveHeader (HttpInstance, &SizeofHeaders, &BufferSize);
-if (EFI_ERROR (Status)) {
+if (EFI_ERROR (Status) || HttpHeaders == NULL) {
goto Error;
}
Reviewed-by: Fu Siyuan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang
Lubo
Sent: Thursday, November 26, 2015 10:01 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin
; Qiu, Shumin
Subject: [edk2] [PATCH v2] NetworkPkg:Fix NULL pointer dereference issues.
v2:
*Revise some codes according to the comments.
1.In HttpResponseWorker, check the HttpHeaders in the first used place.
2.In EfiHttpPoll(), check the HttpInstance state outside of if condition.
Cc: Ye Ting
Cc: Fu Siyuan
Cc: Wu Jiaxin
Cc: Qiu Shumin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
NetworkPkg/HttpDxe/HttpImpl.c | 18 ---
NetworkPkg/HttpDxe/HttpImpl.h | 1 + NetworkPkg/HttpDxe/HttpProto.c | 52
+++---
3 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 4ad07d4..2cda5a7 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -38,10 +38,11 @@ EFI_HTTP_PROTOCOL mEfiHttpTemplate = {
@retval EFI_SUCCESS Operation succeeded.
@retval EFI_INVALID_PARAMETER One or more of the following conditions is
TRUE:
This is NULL.
HttpConfigData is NULL.
HttpConfigData->AccessPoint is NULL.
+ @retval EFI_OUT_OF_RESOURCESCould not allocate enough system resources.
@retval EFI_NOT_STARTED The HTTP instance is not configured.
**/
EFI_STATUS
EFIAPI
@@ -69,18 +70,24 @@ EfiHttpGetModeData (
HttpConfigData->TimeOutMillisec= HttpInstance->TimeOutMillisec;
HttpConfigData->LocalAddressIsIPv6 = HttpInstance->LocalAddressIsIPv6;
if (HttpInstance->LocalAddressIsIPv6) {
Http6AccessPoint = AllocateZeroPool (sizeof (EFI_HTTPv6_ACCESS_POINT));
+if (Http6AccessPoint == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+}
CopyMem (
Http6AccessPoint,
&HttpInstance->Ipv6Node,
sizeof (HttpInstance->Ipv6Node)
);
HttpConfigData->AccessPoint.IPv6Node = Http6AccessPoint;
} else {
Http4AccessPoint = AllocateZeroPool (sizeof (EFI_HTTPv4_ACCESS_POINT));
+if (Http4AccessPoint == NULL) {
+ return EFI_OUT_OF_RESOURCES;
+}
CopyMem (
Http4AccessPoint,
&HttpInstance->IPv4Node,
sizeof (HttpInstance->IPv4Node)
);
@@ -879,11 +886,11 @@ HttpResponseWorker (
HttpInstance->EndofHeader = &EndofHeader;
HttpInstance->HttpHeaders = &HttpHeaders;
Status = HttpTcpReceiveHeader (HttpInstance, &SizeofHeaders, &BufferSize);
-if (EFI_ERROR (Status)) {
+if (EFI_ERROR (Status) || HttpHeaders == NULL) {
goto Error;
}
//
// Cache the part of body.
@@ -1285,18 +1292,23 @@ EfiHttpPoll (
}
HttpInstance = HTTP_INSTANCE_FROM_PROTOCOL (This);
ASSERT (HttpInstance != NULL);
- if (HttpInstance->State != HTTP_STATE_TCP_CONNECTED || (HttpInstance->Tcp4
== NULL &&
- HttpInstance->Tcp6
== NULL)) {
+ if (HttpInstance->State != HTTP_STATE_TCP_CONNECTED) {
return EFI_NOT_STARTED;
}
if (HttpInstance->LocalAddressIsIPv6) {
+if (HttpInstance->Tcp6 == NULL) {
+ return EFI_NOT_STARTED;
+}
Status = HttpInstance->Tcp6->Poll (HttpInstance->Tcp6);
} else {
+if (HttpInstance->Tcp4 == NULL) {
+ return EFI_NOT_STARTED;
+}
Status = HttpInstance->Tcp4->Poll (HttpInstance->Tcp4);
}
DispatchDpc ();
diff --git a/NetworkPkg/HttpDxe/HttpImpl.h b/NetworkPkg/HttpDxe/HttpImpl.h
index 49c8af1..afbe982 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.h
+++ b/NetworkPkg/HttpDxe/HttpImpl.h
Re: [edk2] ifconfig command issue in edk2
Hi Shaveta, Thanks for your finding, we have rootcause the hang issue in ifconfig , and will fix it as soon as possible. Thanks. Jiaxin -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting Sent: Wednesday, December 2, 2015 9:21 AM To: Leekha Shaveta; edk2-devel@lists.01.org Cc: Sharma Bhupesh Subject: Re: [edk2] ifconfig command issue in edk2 Hi Shaveta, We will try to reproduce the ASSERT issue at first. We will investigate how to fix it as soon as we can reproduce this, or back to you once we fail to reproduce. For below one, it seems you split the ifconfig command to two parts, and shell does not recognize the second part as 'con' is not a command. Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static Shell> 192.169 con 'con' is not recognized as an internal or external command, operable program, or script file. Best Regards, Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha Shaveta Sent: Tuesday, December 01, 2015 7:53 PM To: edk2-devel@lists.01.org Cc: Sharma Bhupesh Subject: [edk2] ifconfig command issue in edk2 Hi, I am observing one issue while using "ifconfig" command. When ifconfig command is used with incomplete parameters like below, it hangs the system by throwing an ASSERT: Shell> ifconfig -s eth0 static 192.168.2.142 ASSERT /home/jenkins/ci/sdk/sdk-ls1043a/ls1043ardb/ls1043a-uefi/MdePkg/Library/BaseLib/String.c(173): ((UINTN) String & 0x0001) == 0 Whereas in some other cases, it simply returns to prompt: Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static Shell> 192.169 con 'con' is not recognized as an internal or external command, operable program, or script file. Shell> Is this some known issue or any pointer why is this happening? Regards, Shaveta -Original Message- From: Leekha Shaveta-B20052 Sent: Thursday, September 24, 2015 1:17 PM To: 'Ye, Ting' ; edk2-devel@lists.01.org Subject: RE: Ping 1st packet reply missing Hi Ye Ting Ping issue is resolved now. I found in some old edk2 mails that it was some issue in Ping command implementation(Snippet pasted below). After making TxRing ready beforehand, this issue get resolved now. But TFTP issue is the one, I am still facing, any pointers on that? Thanks and Regards, Shaveta Snippet of that mail chain issue : Re: [edk2] Missing Ping Reply The reason that the reply is missing is because when the reply is received and "Ping6OnEchoReplyReceived" is called, it kicks out in the call to "Ping6MatchEchoReply". The reason that reply does not match because there is no entry in the TxList when reply is received. In the function "PingSendEchoRequest", the ICMP message is sent out first before the entry is inserted into TxList. The reply comes back before the call comes back from "Transmit" function of the IPV4 protocol. -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Thursday, September 24, 2015 1:01 PM To: Leekha Shaveta-B20052 ; edk2-devel@lists.01.org Subject: RE: Ping 1st packet reply missing We did not meet this error before. Could you please share your captured packet and network topology for analysis? Best Regards, Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha Shaveta Sent: Thursday, September 24, 2015 1:45 PM To: edk2-devel@lists.01.org Subject: [edk2] Ping 1st packet reply missing Hi, My ping is working with Intel's E1000 driver code. But everytime 1st packet is not getting received successfully, is there some known issue here, or something to be set/missing? Regards, Shaveta Ping Snippet: === Shell> ping 192.168.3.1ping 192.168.3.1 -n 16 InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 192.168.3.1 16 data bytes. GigAdapter->cur_rx_ind: 0 GigAdapter->cur_rx_ind: 1 16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms GigAdapter->cur_rx_ind: 2 16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms GigAdapter->cur_rx_ind: 3 16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms GigAdapter->cur_rx_ind: 4 16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms GigAdapter->cur_rx_ind: 5 16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms GigAdapter->cur_rx_ind: 6 16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 time=1ms GigAdapter->cur_rx_ind: 7 16 bytes from 192.168.3.1 : icmp_seq=8 ttl=0 time=1ms GigAdapter->cur_rx_ind: 0 16 bytes from 192.168.3.1 : icmp_seq=9 ttl=0 time=1ms GigAdapter->cur_rx_ind: 1 16 bytes from 192.168.3.1 : icmp_seq=10 ttl=0 time=1ms GigAdapter->cur_rx_ind: 2 16 bytes from 192.168.3.1 : icmp_seq=11 ttl=0 time=1ms GigAdapter->cur_rx_ind: 3 16 bytes from 192.168.3.1 : icmp_seq=12 ttl=0 time=1ms GigAdapter->cur_rx_ind: 4 16 bytes from 192.168.3.1 : icmp_seq=13 ttl=0 time=1ms GigAdapter->cur_rx_ind: 5 16 bytes from 192.168.3.1 : icmp_seq=14 ttl=0 time=1ms GigAdapter
Re: [edk2] [Patch] ShellPkg: Fix ifconfig hang issue with incomplete parameters
Hi Shaveta,
How about your test result?
Thanks.
Jiaxin
-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: Tuesday, December 8, 2015 2:21 PM
To: Carsey, Jaben; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Ye, Ting
Subject: RE: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete
parameters
Hi,
Thanks for the fix, I will test it and revert in a day or two.
Regards,
Shaveta
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Friday, December 04, 2015 11:38 PM
To: Wu, Jiaxin ; edk2-devel@lists.01.org
Cc: Leekha Shaveta-B20052 ; Ye, Ting
; Carsey, Jaben
Subject: RE: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete
parameters
Looks good to me. I think we should wait for Leekha for up to a few days to
confirm that this fixes the problem at their location.
Reviewed-by: Jaben Carsey
-Jaben
> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, December 03, 2015 5:27 PM
> To: edk2-devel@lists.01.org
> Cc: Leekha Shaveta ; Carsey, Jaben
> ; Ye, Ting
> Subject: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete
> parameters
> Importance: High
>
> This patch is used to fix ifconfig hang issue with incomplete
> parameters. In addition, some error related output information is
> added to increase the interactivity.
>
> Cc: Leekha Shaveta
> Cc: Carsey Jaben
> Cc: Ye Ting
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> .../UefiShellNetwork1CommandsLib/Ifconfig.c| 61 --
> ---
> .../UefiShellNetwork1CommandsLib.uni | Bin 21094 -> 21256 bytes
> 2 files changed, 47 insertions(+), 14 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> index fb6f575..f8dbc88 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> @@ -826,10 +826,11 @@ IfConfigClearInterfaceInfo (
> Ip4Config2DataTypePolicy,
> sizeof (EFI_IP4_CONFIG2_POLICY),
> &Policy
> );
> if (EFI_ERROR (Status)) {
> + ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>ShellStatus = SHELL_ACCESS_DENIED;
>break;
> }
>}
>
> @@ -902,10 +903,11 @@ IfConfigSetInterfaceInfo (
>NULL,
>NULL,
>&TimeOutEvt
>);
>if (EFI_ERROR (Status)) {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
> ShellStatus = SHELL_ACCESS_DENIED;
> goto ON_EXIT;
>}
>
>Status = gBS->CreateEvent (
> @@ -914,10 +916,11 @@ IfConfigSetInterfaceInfo (
>IfConfigManualAddressNotify,
>&IsAddressOk,
>&MappedEvt
>);
>if (EFI_ERROR (Status)) {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
> ShellStatus = SHELL_ACCESS_DENIED;
> goto ON_EXIT;
>}
>
>//
> @@ -972,10 +975,11 @@ IfConfigSetInterfaceInfo (
> //
> if (StrCmp(VarArg->Arg, L"dhcp") == 0) {
>if (IfCb->Policy == Ip4Config2PolicyDhcp) {
> Status = IfConfigStartIp4 (IfCb->NicHandle, gImageHandle);
> if (EFI_ERROR(Status)) {
> + ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> + (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>ShellStatus = SHELL_ACCESS_DENIED;
>goto ON_EXIT;
> }
>} else {
> //
> @@ -987,74 +991,100 @@ IfConfigSetInterfaceInfo (
> Ip4Config2DataTypePolicy,
> sizeof (EFI_IP4_CONFIG2_POLICY),
> &Policy
> );
> if (EFI_ERROR(Status)) {
> + ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> + (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>ShellStatus = SHELL_ACCESS_DENIED;
>goto ON_EXIT;
> }
>}
>
>VarArg= VarArg->Next;
>
> } else if (StrCmp (VarArg->Arg, L"static") == 0) {
> - //
> - // Set manual config policy.
> - //
> - Policy = Ip4Config2PolicyStatic;
> - Status = IfCb->IfCfg->Se
Re: [edk2] [Patch] NetworkPkg: Enlarge the TCP send/receive buffer in HTTP driver.
Looks good.
Reviewed-by: Jiaxin Wu
-Original Message-
From: Fu, Siyuan
Sent: Friday, December 11, 2015 10:41 AM
To: edk2-de...@ml01.01.org
Cc: Zhang, Lubo; Wu, Jiaxin
Subject: [Patch] NetworkPkg: Enlarge the TCP send/receive buffer in HTTP driver.
This patch enlarges the TCP send/receive buffer to 2M in HttpDxe driver to
speed up the download speed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan
---
NetworkPkg/HttpDxe/HttpProto.c | 22 --
NetworkPkg/HttpDxe/HttpProto.h | 2 +-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index 85f8401..3f6291b 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1063,6 +1063,7 @@ HttpConfigureTcp4 (
Tcp4Option->KeepAliveTime = HTTP_KEEP_ALIVE_TIME;
Tcp4Option->KeepAliveInterval = HTTP_KEEP_ALIVE_INTERVAL;
Tcp4Option->EnableNagle= TRUE;
+ Tcp4Option->EnableWindowScaling= TRUE;
Tcp4CfgData->ControlOption = Tcp4Option;
Status = HttpInstance->Tcp4->Configure (HttpInstance->Tcp4, Tcp4CfgData); @@
-1124,16 +1125,17 @@ HttpConfigureTcp6 (
IP6_COPY_ADDRESS (&Tcp6Ap->RemoteAddress , &HttpInstance->RemoteIpv6Addr);
Tcp6Option = Tcp6CfgData->ControlOption;
- Tcp6Option->ReceiveBufferSize = HTTP_BUFFER_SIZE_DEAULT;
- Tcp6Option->SendBufferSize = HTTP_BUFFER_SIZE_DEAULT;
- Tcp6Option->MaxSynBackLog = HTTP_MAX_SYN_BACK_LOG;
- Tcp6Option->ConnectionTimeout = HTTP_CONNECTION_TIMEOUT;
- Tcp6Option->DataRetries= HTTP_DATA_RETRIES;
- Tcp6Option->FinTimeout = HTTP_FIN_TIMEOUT;
- Tcp6Option->KeepAliveProbes= HTTP_KEEP_ALIVE_PROBES;
- Tcp6Option->KeepAliveTime = HTTP_KEEP_ALIVE_TIME;
- Tcp6Option->KeepAliveInterval = HTTP_KEEP_ALIVE_INTERVAL;
- Tcp6Option->EnableNagle= TRUE;
+ Tcp6Option->ReceiveBufferSize = HTTP_BUFFER_SIZE_DEAULT;
+ Tcp6Option->SendBufferSize = HTTP_BUFFER_SIZE_DEAULT;
+ Tcp6Option->MaxSynBackLog = HTTP_MAX_SYN_BACK_LOG;
+ Tcp6Option->ConnectionTimeout = HTTP_CONNECTION_TIMEOUT;
+ Tcp6Option->DataRetries = HTTP_DATA_RETRIES;
+ Tcp6Option->FinTimeout = HTTP_FIN_TIMEOUT;
+ Tcp6Option->KeepAliveProbes = HTTP_KEEP_ALIVE_PROBES;
+ Tcp6Option->KeepAliveTime = HTTP_KEEP_ALIVE_TIME;
+ Tcp6Option->KeepAliveInterval = HTTP_KEEP_ALIVE_INTERVAL;
+ Tcp6Option->EnableNagle = TRUE;
+ Tcp6Option->EnableWindowScaling = TRUE;
Status = HttpInstance->Tcp6->Configure (HttpInstance->Tcp6, Tcp6CfgData);
if (EFI_ERROR (Status)) {
diff --git a/NetworkPkg/HttpDxe/HttpProto.h b/NetworkPkg/HttpDxe/HttpProto.h
index e43a2dc..291bb14 100644
--- a/NetworkPkg/HttpDxe/HttpProto.h
+++ b/NetworkPkg/HttpDxe/HttpProto.h
@@ -43,7 +43,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
//
#define HTTP_TOS_DEAULT 8
#define HTTP_TTL_DEAULT 255
-#define HTTP_BUFFER_SIZE_DEAULT 65535
+#define HTTP_BUFFER_SIZE_DEAULT 0x20
#define HTTP_MAX_SYN_BACK_LOG5
#define HTTP_CONNECTION_TIMEOUT 60
#define HTTP_DATA_RETRIES12
--
2.5.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg: Remove a CopyMem to speed up the HTTP boot download.
Looks good.
Reviewed-by: Jiaxin Wu
-Original Message-
From: Fu, Siyuan
Sent: Friday, December 11, 2015 10:17 AM
To: edk2-de...@ml01.01.org
Cc: Zhang, Lubo; Wu, Jiaxin
Subject: [Patch] NetworkPkg: Remove a CopyMem to speed up the HTTP boot
download.
This patch updates the HTTP boot driver to use the caller provided buffer
directly in identity transfer-coding mode, this could save one time CopyMem
operation to benefit the download performance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan
---
NetworkPkg/HttpBootDxe/HttpBootClient.c | 271 +++-
1 file changed, 163 insertions(+), 108 deletions(-)
diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c
b/NetworkPkg/HttpBootDxe/HttpBootClient.c
index b81b03c..a2cad0a 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
+++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
@@ -457,81 +457,6 @@ HttpBootCreateHttpIo ( }
/**
- Get the file content from cached data.
-
- @param[in] Private The pointer to the driver's private data.
- @param[in] Uri Uri of the file to be retrieved from
cache.
- @param[in, out] BufferSize On input the size of Buffer in bytes. On
output with a return
- code of EFI_SUCCESS, the amount of data
transferred to
- Buffer. On output with a return code of
EFI_BUFFER_TOO_SMALL,
- the size of Buffer required to retrieve
the requested file.
- @param[out] Buffer The memory buffer to transfer the file
to. IF Buffer is NULL,
- then the size of the requested file is
returned in
- BufferSize.
-
- @retval EFI_SUCCESS Successfully created.
- @retval Others Failed to create HttpIo.
-
-**/
-EFI_STATUS
-HttpBootGetFileFromCache (
- IN HTTP_BOOT_PRIVATE_DATA *Private,
- IN CHAR16 *Uri,
- IN OUT UINTN*BufferSize,
- OUT UINT8*Buffer
- )
-{
- LIST_ENTRY *Entry;
- LIST_ENTRY *Entry2;
- HTTP_BOOT_CACHE_CONTENT *Cache;
- HTTP_BOOT_ENTITY_DATA *EntityData;
- UINTN CopyedSize;
-
- if (Uri == NULL || BufferSize == 0 || Buffer == NULL) {
-return EFI_INVALID_PARAMETER;
- }
-
- NET_LIST_FOR_EACH (Entry, &Private->CacheList) {
-Cache = NET_LIST_USER_STRUCT (Entry, HTTP_BOOT_CACHE_CONTENT, Link);
-//
-// Compare the URI to see whether we already have a cache for this file.
-//
-if ((Cache->RequestData != NULL) &&
-(Cache->RequestData->Url != NULL) &&
-(StrCmp (Uri, Cache->RequestData->Url) == 0))
-{
- //
- // Hit cache, check buffer size.
- //
- if (*BufferSize < Cache->EntityLength) {
-*BufferSize = Cache->EntityLength;
-return EFI_BUFFER_TOO_SMALL;
- }
-
- //
- // Fill data to buffer.
- //
- CopyedSize = 0;
- NET_LIST_FOR_EACH (Entry2, &Cache->EntityDataList) {
-EntityData = NET_LIST_USER_STRUCT (Entry2, HTTP_BOOT_ENTITY_DATA,
Link);
-if (*BufferSize > CopyedSize) {
- CopyMem (
-Buffer + CopyedSize,
-EntityData->DataStart,
-MIN (EntityData->DataLength, *BufferSize - CopyedSize)
-);
- CopyedSize += MIN (EntityData->DataLength, *BufferSize - CopyedSize);
-}
- }
- *BufferSize = CopyedSize;
- return EFI_SUCCESS;
-}
- }
-
- return EFI_NOT_FOUND;
-}
-
-/**
Release all the resource of a cache item.
@param[in] Cache The pointer to the cache item.
@@ -610,6 +535,91 @@ HttpBootFreeCacheList ( }
/**
+ Get the file content from cached data.
+
+ @param[in] Private The pointer to the driver's private data.
+ @param[in] Uri Uri of the file to be retrieved from
cache.
+ @param[in, out] BufferSize On input the size of Buffer in bytes. On
output with a return
+ code of EFI_SUCCESS, the amount of data
transferred to
+ Buffer. On output with a return code of
EFI_BUFFER_TOO_SMALL,
+ the size of Buffer required to retrieve
the requested file.
+ @param[out] Buffer The memory buffer to transfer the file
to. IF Buffer is NULL,
+ then the size of the requested file is
returned in
+ BufferSize.
+
+ @retval EFI_SUCCESS Successfully created.
+ @retval Others Failed to create HttpIo.
+
+**/
+EFI_STATUS
+HttpBootGetFileFromCache (
+ IN HTTP_BOOT_PRIVATE_DATA *Private,
+ IN C
Re: [edk2] [patch] NetworkPkg:Fix the issue Http boot hang when network failed.
Reviewed-by: Jiaxin Wu
-Original Message-
From: Zhang, Lubo
Sent: Tuesday, December 15, 2015 11:36 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin
Subject: [patch] NetworkPkg:Fix the issue Http boot hang when network failed.
For both IPv4 and IPv6, when network transfer failed, such as disconnected
cable or disable http server, HTTP boot should exit back to the menu UI rather
than hang.
Cc: Ye Ting
Cc: Fu Siyuan
Cc: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
NetworkPkg/HttpDxe/HttpProto.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index 85f8401..165e95c 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -148,17 +148,23 @@ HttpTcpReceiveNotifyDpc (
if (UsingIpv6) {
gBS->CloseEvent (Wrap->TcpWrap.Rx6Token.CompletionToken.Event);
if (EFI_ERROR (Wrap->TcpWrap.Rx6Token.CompletionToken.Status)) {
+ Wrap->HttpToken->Status = Wrap->TcpWrap.Rx6Token.CompletionToken.Status;
+ gBS->SignalEvent (Wrap->HttpToken->Event);
+ FreePool (Wrap);
return ;
}
} else {
gBS->CloseEvent (Wrap->TcpWrap.Rx4Token.CompletionToken.Event);
if (EFI_ERROR (Wrap->TcpWrap.Rx4Token.CompletionToken.Status)) {
+ Wrap->HttpToken->Status = Wrap->TcpWrap.Rx4Token.CompletionToken.Status;
+ gBS->SignalEvent (Wrap->HttpToken->Event);
+ FreePool (Wrap);
return ;
}
}
//
--
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] MdeModulePkg:Fix a bug HttpLib can't parse last chunked data well
Reviewed-by: Jiaxin Wu
-Original Message-
From: Zhang, Lubo
Sent: Wednesday, December 16, 2015 3:26 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan; Ye, Ting; Wu, Jiaxin
Subject: [patch] MdeModulePkg:Fix a bug HttpLib can't parse last chunked data
well
When HttpLib parsing the last chunked data down, the Http NextMsg pointer in
the HttpBodyParserCallback function should point to the character after '/n'
flag.
Cc: Fu Siyuan
Cc: Ye Ting
Cc: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 39 +---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
index 49fa80b..143baab 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
@@ -1159,25 +1159,11 @@ HttpParseMessageBody (
for (Char = Body; Char < Body + BodyLength; ) {
switch (Parser->State) {
case BodyParserStateMax:
return EFI_ABORTED;
-
-case BodyParserComplete:
- if (Parser->Callback != NULL) {
-Status = Parser->Callback (
- BodyParseEventOnComplete,
- Char,
- 0,
- Parser->Context
- );
-if (EFI_ERROR (Status)) {
- return Status;
-}
- }
- return EFI_SUCCESS;
-
+
case BodyParserBodyIdentity:
//
// Identity transfer-coding, just notify user to save the body data.
//
if (Parser->Callback != NULL) {
@@ -1193,10 +1179,21 @@ HttpParseMessageBody (
}
Char += MIN (BodyLength, Parser->ContentLength -
Parser->ParsedBodyLength);
Parser->ParsedBodyLength += MIN (BodyLength, Parser->ContentLength -
Parser->ParsedBodyLength);
if (Parser->ParsedBodyLength == Parser->ContentLength) {
Parser->State = BodyParserComplete;
+if (Parser->Callback != NULL) {
+ Status = Parser->Callback (
+ BodyParseEventOnComplete,
+ Char,
+ 0,
+ Parser->Context
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+}
}
break;
case BodyParserChunkSizeStart:
//
@@ -1270,10 +1267,22 @@ HttpParseMessageBody (
}
case BodyParserLastCRLFEnd:
if (*Char == '\n') {
Parser->State = BodyParserComplete;
+Char++;
+if (Parser->Callback != NULL) {
+ Status = Parser->Callback (
+ BodyParseEventOnComplete,
+ Char,
+ 0,
+ Parser->Context
+ );
+ if (EFI_ERROR (Status)) {
+return Status;
+ }
+}
break;
} else {
Parser->State = BodyParserStateMax;
break;
}
--
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] NetworkPkg:Fix a bug the 2nd httpboot fail issue.
Reviewed-by: Jiaxin Wu
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang
Lubo
Sent: Friday, December 18, 2015 10:32 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin
Subject: [edk2] [patch] NetworkPkg:Fix a bug the 2nd httpboot fail issue.
Httpboot over Ipv4 or Ipv6 stack,for both Identity and chunked transfer
mode,when the last data has been parsed by HttpLib, the HttpInstance->NextMsg
pointer should point a correct location.Now after the first successful httpboot
for ipv4 or ipv6,the HttpInstance->NextMsg point the character after the last
byte, it may be a bad buffer if we don't receive another HttpHeader, so if call
a 2nd httpboot, the wrong NextMsg pointer will cause the httpboot fail, so we
need to check this case in HttpBodyParserCallback function in the first http
boot process.
Cc: Fu Siyuan
Cc: Ye Ting
Cc: Wu Jiaxin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo
---
NetworkPkg/HttpDxe/HttpImpl.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 0fa437d..aee3de5 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -776,21 +776,30 @@ HttpBodyParserCallback (
IN UINTN Length,
IN VOID *Context
)
{
HTTP_TOKEN_WRAP *Wrap;
+ UINTN BodyLength;
+ CHAR8 *Body;
if (EventType != BodyParseEventOnComplete) {
return EFI_SUCCESS;
}
if (Data == NULL || Length != 0 || Context == NULL) {
return EFI_SUCCESS;
}
Wrap = (HTTP_TOKEN_WRAP *) Context;
- Wrap->HttpInstance->NextMsg = Data;
+ Body = Wrap->HttpToken->Message->Body; BodyLength =
+ Wrap->HttpToken->Message->BodyLength;
+ if (Data < Body + BodyLength) {
+Wrap->HttpInstance->NextMsg = Data; } else {
+Wrap->HttpInstance->NextMsg = NULL; }
+
//
// Free Tx4Token or Tx6Token since already received corrsponding HTTP
response.
//
FreePool (Wrap);
--
1.9.5.msysgit.1
___
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] [Patch 1/2] MdeModulePkg: update SNP.GetStatus to handle multiple recycled TX buffer.
Suggest to initialize the point "Tmp" while it maybe not used if
GetTransmittedBuf is false. Others good to me.
>UINT64*Tmp;
>Tmp = NULL;
Reviewed-by: Jiaxin Wu
-Original Message-
From: Ye, Ting
Sent: Thursday, December 17, 2015 5:04 PM
To: Fu, Siyuan; edk2-de...@ml01.01.org
Cc: Wu, Jiaxin; Tian, Feng
Subject: RE: [Patch 1/2] MdeModulePkg: update SNP.GetStatus to handle multiple
recycled TX buffer.
Siyuan,
Some minor comments to this patch:
1) Copyright year in Get_status.c is not updated to latest.
2) Parameter in PxeGetStatus() is updated though you did not update the
corresponding function description.
Reviewed-by: Ye Ting
Thanks,
Ting
-Original Message-
From: Fu, Siyuan
Sent: Tuesday, December 15, 2015 3:59 PM
To: edk2-de...@ml01.01.org
Cc: Ye, Ting; Wu, Jiaxin; Tian, Feng
Subject: [Patch 1/2] MdeModulePkg: update SNP.GetStatus to handle multiple
recycled TX buffer.
This patch fixes a bug in SNP.GetStatus() interface. The UNDI driver may return
multiple transmitted buffers in a single GetStatus command, while SNP.GetStatus
could only return one pointer each time, the rest of them are lost. This patch
fixes this issue by store these recycled pointer in a temporary buffer in SNP
driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan
---
MdeModulePkg/Universal/Network/SnpDxe/Get_status.c | 63 ++
MdeModulePkg/Universal/Network/SnpDxe/Snp.c| 14 +
MdeModulePkg/Universal/Network/SnpDxe/Snp.h| 15 +-
3 files changed, 81 insertions(+), 11 deletions(-)
diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
b/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
index 0532976..379aaa6 100644
--- a/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
+++ b/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
@@ -35,19 +35,22 @@ EFI_STATUS
PxeGetStatus (
SNP_DRIVER *Snp,
UINT32 *InterruptStatusPtr,
- VOID **TransmitBufferListPtr
+ BOOLEANGetTransmittedBuf
)
{
PXE_DB_GET_STATUS *Db;
UINT16InterruptFlags;
+ UINT32Index;
+ UINT64*Tmp;
Db= Snp->Db;
Snp->Cdb.OpCode = PXE_OPCODE_GET_STATUS;
Snp->Cdb.OpFlags = 0;
- if (TransmitBufferListPtr != NULL) {
+ if (GetTransmittedBuf) {
Snp->Cdb.OpFlags |= PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS;
+ZeroMem (Db->TxBuffer, sizeof (Db->TxBuffer));
}
if (InterruptStatusPtr != NULL) {
@@ -116,13 +119,37 @@ PxeGetStatus (
}
- if (TransmitBufferListPtr != NULL) {
-*TransmitBufferListPtr =
- (
-((Snp->Cdb.StatFlags & PXE_STATFLAGS_GET_STATUS_NO_TXBUFS_WRITTEN) !=
0) ||
-((Snp->Cdb.StatFlags & PXE_STATFLAGS_GET_STATUS_TXBUF_QUEUE_EMPTY) !=
0)
- ) ? 0 : (VOID *) (UINTN) Db->TxBuffer[0];
-
+ if (GetTransmittedBuf) {
+DEBUG ((EFI_D_INFO, "PxeGetStatus: try to recycle TxBuf, StatFlags =
0x%X\n", Snp->Cdb.StatFlags));
+if ((Snp->Cdb.StatFlags & PXE_STATFLAGS_GET_STATUS_NO_TXBUFS_WRITTEN) ==
0) {
+ //
+ // UNDI has written some transmitted buffer addresses into the DB. Store
them into Snp->RecycledTxBuf.
+ //
+ for (Index = 0; Index < MAX_XMIT_BUFFERS; Index++) {
+if (Db->TxBuffer[Index] != 0) {
+ if (Snp->RecycledTxBufCount == Snp->MaxRecycledTxBuf) {
+//
+// Snp->RecycledTxBuf is full, reallocate a new one.
+//
+if ((Snp->MaxRecycledTxBuf + SNP_TX_BUFFER_INCREASEMENT) >=
SNP_MAX_TX_BUFFER_NUM) {
+ return EFI_DEVICE_ERROR;
+}
+Tmp = AllocatePool (sizeof (UINT64) * (Snp->MaxRecycledTxBuf +
SNP_TX_BUFFER_INCREASEMENT));
+if (Tmp == NULL) {
+ return EFI_DEVICE_ERROR;
+}
+CopyMem (Tmp, Snp->RecycledTxBuf, sizeof (UINT64) *
Snp->RecycledTxBufCount);
+FreePool (Snp->RecycledTxBuf);
+Snp->RecycledTxBuf= Tmp;
+Snp->MaxRecycledTxBuf += SNP_TX_BUFFER_INCREASEMENT;
+ }
+ DEBUG ((EFI_D_INFO, "PxeGetStatus: recycled %lx\n",
Db->TxBuffer[Index]));
+ Snp->RecycledTxBuf[Snp->RecycledTxBufCount] = Db->TxBuffer[Index];
+ Snp->RecycledTxBufCount++;
+}
+ }
+ DEBUG ((EFI_D_INFO, "PxeGetStatus: %d TxBuf in recycled queue\n",
Snp->RecycledTxBufCount));
+}
}
//
@@ -216,7 +243,23 @@ SnpUndi32GetStatus (
goto ON_EXIT;
}
- Status = PxeGetStatus (Snp, InterruptStatus, TxBuf);
+ if (Snp->RecycledTxBufCount == 0 && TxBuf != NULL) {
+Status = PxeGetStatus (Snp, InterruptStatus, TRUE); } else {
+Status = PxeGetStatus (Snp, InterruptStatus, FALSE); }
+
+ if (TxBuf != NULL) {
+//
+// Get a recycled buf from Snp->RecycledTxBuf
+//
+if (Snp->Recy
Re: [edk2] [Patch 7/8] NetworkPkg: Update module inf to include the missing uni file
Reviewed-by: Jiaxin Wu -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming Gao Sent: Wednesday, December 23, 2015 5:57 PM To: edk2-devel@lists.01.org Subject: [edk2] [Patch 7/8] NetworkPkg: Update module inf to include the missing uni file Update DnsDxe and HttpUtilitiesDxe inf files. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- NetworkPkg/DnsDxe/DnsDxe.inf | 5 +++-- NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/NetworkPkg/DnsDxe/DnsDxe.inf b/NetworkPkg/DnsDxe/DnsDxe.inf index 0d1efd8..bf9dc3d 100644 --- a/NetworkPkg/DnsDxe/DnsDxe.inf +++ b/NetworkPkg/DnsDxe/DnsDxe.inf @@ -22,6 +22,7 @@ VERSION_STRING= 1.0 ENTRY_POINT = DnsDriverEntryPoint UNLOAD_IMAGE = DnsUnload + MODULE_UNI_FILE = DnsDxe.uni [Packages] MdePkg/MdePkg.dec @@ -73,6 +74,6 @@ gEfiDhcp6ServiceBindingProtocolGuid ## SOMETIMES_CONSUMES gEfiDhcp6ProtocolGuid ## SOMETIMES_CONSUMES - -[Guids] +[UserExtensions.TianoCore."ExtraFiles"] + DnsDxeExtra.uni diff --git a/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf index c101e6f..ffdbcd5 100644 --- a/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf +++ b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf @@ -21,6 +21,7 @@ VERSION_STRING= 1.0 ENTRY_POINT = HttpUtilitiesDxeDriverEntryPoint UNLOAD_IMAGE = HttpUtilitiesDxeUnload + MODULE_UNI_FILE = HttpUtilitiesDxe.uni [Packages] MdePkg/MdePkg.dec @@ -47,5 +48,5 @@ [Depex] TRUE -[Guids] - +[UserExtensions.TianoCore."ExtraFiles"] + HttpUtilitiesDxeExtra.uni -- 1.9.5.msysgit.0 ___ 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] [Patch] NetworkPkg: Support DNS4/6 GeneralLookUp feature
Thanks Ting's comments. I will update it by the comments.
-Original Message-
From: Ye, Ting
Sent: Thursday, December 24, 2015 4:27 PM
To: Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Subramanian Sriram; El-Haj-Mahmoud Samer; Fu, Siyuan
Subject: RE: [Patch] NetworkPkg: Support DNS4/6 GeneralLookUp feature
Some comments for the patch:
1. DnsFillQuerytIpQName:
a. returns UIN8* though in function description it returns EFI_STATUS.
b. better to record how QName is defined in RFC.
c. It is an internal function so I don't think it needs EFIAPI attribute.
d. when calling DnsFillQuerytIpQName, the comment " Construct QName, QType
and QClass" is incorrect.
e. Might update the function name to DnsFillinQName(ForQueryIp)?
2. ParseDnsResponse:
a. Typo "ResouseRecord"
b. Coding style issue: the block for "Check whether it's the GeneralLookUp
querying" is not good aligned.
Reviewed-by: Ye Ting
Thanks,
Ting
-Original Message-
From: Wu, Jiaxin
Sent: Thursday, December 17, 2015 2:44 PM
To: edk2-devel@lists.01.org
Cc: Subramanian Sriram; El-Haj-Mahmoud Samer; Ye, Ting; Fu, Siyuan
Subject: [Patch] NetworkPkg: Support DNS4/6 GeneralLookUp feature
This patch is used to support DNS4/6 GeneralLookUp feature.
Cc: Subramanian Sriram
Cc: El-Haj-Mahmoud Samer
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu
---
NetworkPkg/DnsDxe/DnsImpl.c | 251 ++--
NetworkPkg/DnsDxe/DnsImpl.h | 31 -
NetworkPkg/DnsDxe/DnsProtocol.c | 247 ++-
3 files changed, 455 insertions(+), 74 deletions(-)
diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c index
4f7320e..7a89c4e 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -1012,10 +1012,59 @@ AddDns6ServerIp (
return EFI_SUCCESS;
}
/**
+ Fill QName for IP querying.
+
+ @param HostName Queried HostName
+
+ @retval EFI_SUCCESS QName filled successfully.
+ @retval OthersFailed to fill QName.
+
+**/
+UINT8 *
+EFIAPI
+DnsFillQuerytIpQName (
+ IN CHAR16 *HostName
+ )
+{
+ CHAR8 *QueryName;
+ CHAR8 *Header;
+ CHAR8 *Tail;
+ UINTN Len;
+ UINTN Index;
+
+ QueryName = NULL;
+ Header = NULL;
+ Tail = NULL;
+
+ QueryName = AllocateZeroPool (DNS_DEFAULT_BLKSIZE); ASSERT
+ (QueryName != NULL);
+
+ Header = QueryName;
+ Tail = Header + 1;
+ Len = 0;
+ for (Index = 0; HostName[Index] != 0; Index++) {
+*Tail = (CHAR8) HostName[Index];
+if (*Tail == '.') {
+ *Header = (CHAR8) Len;
+ Header = Tail;
+ Tail ++;
+ Len = 0;
+} else {
+ Tail++;
+ Len++;
+}
+ }
+ *Header = (CHAR8) Len;
+ *Tail = 0;
+
+ return QueryName;
+}
+
+/**
Find out whether the response is valid or invalid.
@param TokensMap All DNS transmittal Tokens entry.
@param Identification Identification for queried packet.
@param TypeType for queried packet.
@@ -1098,34 +1147,42 @@ ParseDnsResponse (
NET_MAP_ITEM *Item;
DNS4_TOKEN_ENTRY *Dns4TokenEntry;
DNS6_TOKEN_ENTRY *Dns6TokenEntry;
UINT32IpCount;
+ UINT32RRCount;
UINT32AnswerSectionNum;
EFI_IPv4_ADDRESS *HostAddr4;
EFI_IPv6_ADDRESS *HostAddr6;
EFI_DNS4_CACHE_ENTRY *Dns4CacheEntry;
EFI_DNS6_CACHE_ENTRY *Dns6CacheEntry;
+ DNS_RESOURCE_RECORD *Dns4RR;
+ DNS6_RESOURCE_RECORD *Dns6RR;
+
EFI_STATUSStatus;
EFI_TPL OldTpl;
Item = NULL;
Dns4TokenEntry = NULL;
Dns6TokenEntry = NULL;
IpCount = 0;
+ RRCount = 0;
AnswerSectionNum = 0;
HostAddr4= NULL;
HostAddr6= NULL;
Dns4CacheEntry = NULL;
Dns6CacheEntry = NULL;
+
+ Dns4RR = NULL;
+ Dns6RR = NULL;
*Completed = TRUE;
Status = EFI_SUCCESS;
//
@@ -1195,33 +1252,61 @@ ParseDnsResponse (
if (Item->Value != NULL) {
NetbufFree ((NET_BUF *) (Item->Value));
}
//
- // Check the Query type, do some buffer allocations.
+ // Do some buffer allocations.
//
if (Instance->Service->IpVersion == IP_VERSION_4) {
ASSERT (Dns4TokenEntry != NULL);
-if (QuerySection->Type == DNS_TYPE_A) {
- Dns4TokenEntry->Token->RspData.H2AData = AllocatePool (sizeof
(DNS_HOST_TO_ADDR_DATA));
- ASSERT (Dns4TokenEntry->Token->RspData.H2AData != NULL);
- Dns4TokenEntry->Token->RspData.H2AData->IpList = AllocatePool
(DnsHeader->AnswersNum * sizeof (EFI_IPv4_ADDRESS));
- ASSERT (Dns4TokenEntry->Token->RspData.H2AData->IpList !=
Re: [edk2] [Patch] NetworkPkg: Fix suspicious dereference of pointer before NULL check
Hi Lindholm,
Sorry that misunderstand you, this patch just make the code more readable. We
know it's impossible return NULL pointer after LocateHandleBuffer returns
EFI_SUCCESS according UEFI Spec or any code logic, but if anyone doesn't have
those knowledge(or unaware of checking UEFI Spec/any code logic), he maybe
thought AipHandleBuffer is suspicious dereference of pointer especially with
below piece code:
...
Exit:
...
if (AipHandleBuffer != NULL) {
FreePool (AipHandleBuffer);
}
...
Thanks.
Jiaxin
-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: Monday, December 28, 2015 12:48 AM
To: Wu, Jiaxin
Cc: edk2-devel@lists.01.org; Ye, Ting; Fu, Siyuan
Subject: Re: [edk2] [Patch] NetworkPkg: Fix suspicious dereference of pointer
before NULL check
Hi Jiaxin,
On Thu, Dec 24, 2015 at 02:16:53PM +0800, Jiaxin Wu wrote:
> This patch is used to fix suspicious dereference of pointer before
> NULL check in IScsiDxe driver.
So, I realise this has already been committed, and I don't see anything wrong
with the code - but the commit message does not appear to be describing what is
actually being done.
> Cc: Ye Ting
> Cc: Fu Siyuan
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> NetworkPkg/IScsiDxe/IScsiDriver.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.c
> b/NetworkPkg/IScsiDxe/IScsiDriver.c
> index a7031df..51ce169 100644
> --- a/NetworkPkg/IScsiDxe/IScsiDriver.c
> +++ b/NetworkPkg/IScsiDxe/IScsiDriver.c
> @@ -103,11 +103,12 @@ IScsiCheckAip (
>UINT8NetworkBootPolicy;
>
>//
>// Check any AIP instances exist in system.
>//
> - AipHandleCount = 0;
> + AipHandleCount = 0;
> + AipHandleBuffer = NULL;
>Status = gBS->LocateHandleBuffer (
>ByProtocol,
>&gEfiAdapterInformationProtocolGuid,
>NULL,
>&AipHandleCount,
> @@ -115,10 +116,12 @@ IScsiCheckAip (
>);
>if (EFI_ERROR (Status) || AipHandleCount == 0) {
> return EFI_NOT_FOUND;
>}
>
> + ASSERT (AipHandleBuffer != NULL);
> +
The change is simply an ASSERT checking whether AipHandleBuffer contains a
valid pointer after successfully returning a non-empty set.
But surely this is a requirement if LocateHandleBuffer returns EFI_SUCCESS?
So what error condition is this change resolving?
Is this to deal with a compiler warning?
>InfoBlock = NULL;
>
>for (AipIndex = 0; AipIndex < AipHandleCount; AipIndex++) {
> Status = gBS->HandleProtocol (
> AipHandleBuffer[AipIndex],
> --
> 1.9.5.msysgit.1
>
> ___
> 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] [Patch] NetworkPkg: Fix suspicious dereference of pointer before NULL check
Leif,
As you mentioned you prefer clarifications instead of any testes
(AipHandleCount and AipHandleBuffer) checking, I don't have strong opinion for
adding more tests checking for API or adding the clarifications on the
guaranteed behavior of the code. I think both of them good to me.
If you want to create another patch for the clarifications, please also remove
the untrusted checks for LocateHandleBuffer() thoroughly.
Thanks.
Jiaxin
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
Lindholm
Sent: Thursday, December 31, 2015 7:00 PM
To: Wu, Jiaxin
Cc: Ye, Ting; edk2-devel@lists.01.org; Fu, Siyuan
Subject: Re: [edk2] [Patch] NetworkPkg: Fix suspicious dereference of pointer
before NULL check
Hi Jiaxin,
On Mon, Dec 28, 2015 at 05:41:56AM +0000, Wu, Jiaxin wrote:
> Hi Lindholm,
> Sorry that misunderstand you, this patch just make the code more
> readable. We know it's impossible return NULL pointer after
> LocateHandleBuffer returns EFI_SUCCESS according UEFI Spec or any code
> logic, but if anyone doesn't have those knowledge(or unaware of
> checking UEFI Spec/any code logic), he maybe thought AipHandleBuffer
> is suspicious dereference of pointer especially with below piece
> code:
>
> ...
> Exit:
> ...
> if (AipHandleBuffer != NULL) {
> FreePool (AipHandleBuffer);
> }
> ...
Thank you.
Ok, this makes me understand why the change was made, and would have been good
to have covered in the commit message. I realise there is a bit of a language
issue here as well. With your explanation, I can see what the commit message is
intended to mean. But just reading the message on its own does not convey this
meaning to me.
If the message had contained more information, this would have been less of a
problem.
And I am not saying that the change is bad, but I will make an observation on
that piece of code in general:
It looks like it does not trust the APIs it is using.
This applies both before and after this specific commit.
We start out with:
---
if (EFI_ERROR (Status) || AipHandleCount == 0) {
return EFI_NOT_FOUND;
}
---
But we already know that LocateHandleBuffer returns EFI_NOT_FOUND if no handles
were found. So the added test for AipHandleCount adds no added confidence to
the program.
Similarily, we know that if LocateHandleBuffer returns EFI_SUCCESS,
AipHandleBuffer contains a valid pointer.
Thus, both of these tests (AipHandleCount and AipHandleBuffer) are checking for
API compliance rather than execution time success. This makes sense in a test
suite, but not in core runtime code.
I do agree with you that this behaviour is not obvious unless I read it with
the UEFI specification next to me, but I would very much prefer clarifications
on the guaranteed behaviour of the code to be made in the form of comments. So
the way I would have written this code would have been:
---
Status = gBS->LocateHandleBuffer (
ByProtocol,
&gEfiAdapterInformationProtocolGuid,
NULL,
&AipHandleCount,
&AipHandleBuffer
);
if (EFI_ERROR(Status)) {
return EFI_NOT_FOUND;
}
// Guaranteed that AipHandleCount > 0 and AipHandleBuffer != NULL
---
Now, the compiler also does not know about the UEFI specification - and
especially more recent GCC versions frequently complain in instances like this.
That was why I was wondering if you were working around a compiler problem.
The explicit initializations
---
AipHandleCount = 0;
AipHandleBuffer = NULL;
---
resolve this problem.
Ting: would you accept a patch that did the above - replacing the additional
test and the ASSERT() with a comment?
Regards,
Leif
> Thanks.
> Jiaxin
>
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, December 28, 2015 12:48 AM
> To: Wu, Jiaxin
> Cc: edk2-devel@lists.01.org; Ye, Ting; Fu, Siyuan
> Subject: Re: [edk2] [Patch] NetworkPkg: Fix suspicious dereference of
> pointer before NULL check
>
> Hi Jiaxin,
>
> On Thu, Dec 24, 2015 at 02:16:53PM +0800, Jiaxin Wu wrote:
> > This patch is used to fix suspicious dereference of pointer before
> > NULL check in IScsiDxe driver.
>
> So, I realise this has already been committed, and I don't see anything wrong
> with the code - but the commit message does not appear to be describing what
> is actually being done.
>
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiaxin Wu
> > ---
> > NetworkPkg/IScsiDxe/IScsiDriver.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/NetworkPkg/IScsiDxe/IScsiD
Re: [edk2] [PATCH v2] MdeModulePkg: Update MNP driver to recycle TX buffer asynchronously.
Siyuan,
Some small comments:
1. Please update MnpBuildTxPacket() function's description.
2. Since Mnp Sent the packet asynchronously, MnpSyncSendPacket() function's
name is improper, the corresponding description also should be updated.
Other parts good to me.
Reviewed-by: Jiaxin Wu
Thanks.
Jiaxin
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu Siyuan
Sent: Tuesday, January 5, 2016 11:37 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Wu, Jiaxin
Subject: [edk2] [PATCH v2] MdeModulePkg: Update MNP driver to recycle TX buffer
asynchronously.
This patch updates the MNP driver to recycle TX buffer asynchronously, instead
of using a while loop wait after each transmit command.
This patch also fixes a bug in SNP.GetStatus() interface to support the MNP
update. The UNDI driver may return multiple transmitted buffers in a single
GetStatus command, while SNP.GetStatus could only return one pointer each time,
the rest of them are lost. This patch fixes this issue by store these recycled
pointer in a temporary buffer in SNP driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan
---
MdeModulePkg/Universal/Network/MnpDxe/MnpConfig.c | 266 ++---
MdeModulePkg/Universal/Network/MnpDxe/MnpDriver.h | 7 +-
MdeModulePkg/Universal/Network/MnpDxe/MnpImpl.h| 45 +++-
MdeModulePkg/Universal/Network/MnpDxe/MnpIo.c | 118 -
MdeModulePkg/Universal/Network/MnpDxe/MnpMain.c| 7 +-
MdeModulePkg/Universal/Network/SnpDxe/Get_status.c | 73 --
MdeModulePkg/Universal/Network/SnpDxe/Snp.c| 16 +-
MdeModulePkg/Universal/Network/SnpDxe/Snp.h| 18 +-
8 files changed, 421 insertions(+), 129 deletions(-)
diff --git a/MdeModulePkg/Universal/Network/MnpDxe/MnpConfig.c
b/MdeModulePkg/Universal/Network/MnpDxe/MnpConfig.c
index 046d4df..d1a4cb5 100644
--- a/MdeModulePkg/Universal/Network/MnpDxe/MnpConfig.c
+++ b/MdeModulePkg/Universal/Network/MnpDxe/MnpConfig.c
@@ -1,7 +1,7 @@
/** @file
Implementation of Managed Network Protocol private services.
-Copyright (c) 2005 - 2012, Intel Corporation. All rights reserved.
+Copyright (c) 2005 - 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 @@ -209,6 +209,208 @@ MnpFreeNbuf (
gBS->RestoreTPL (OldTpl);
}
+/**
+ Add Count of TX buffers to MnpDeviceData->AllTxBufList and
MnpDeviceData->FreeTxBufList.
+ The length of the buffer is specified by MnpDeviceData->BufferLength.
+
+ @param[in, out] MnpDeviceData Pointer to the MNP_DEVICE_DATA.
+ @param[in] Count Number of TX buffers to add.
+
+ @retval EFI_SUCCESS The specified amount of TX buffers are
allocated.
+ @retval EFI_OUT_OF_RESOURCES Failed to allocate a TX buffer.
+
+**/
+EFI_STATUS
+MnpAddFreeTxBuf (
+ IN OUT MNP_DEVICE_DATA *MnpDeviceData,
+ IN UINTN Count
+ )
+{
+ EFI_STATUSStatus;
+ UINT32Index;
+ MNP_TX_BUF_WRAP *TxBufWrap;
+
+ NET_CHECK_SIGNATURE (MnpDeviceData, MNP_DEVICE_DATA_SIGNATURE);
+ ASSERT ((Count > 0) && (MnpDeviceData->BufferLength > 0));
+
+ Status = EFI_SUCCESS;
+ for (Index = 0; Index < Count; Index++) {
+TxBufWrap = (MNP_TX_BUF_WRAP*) AllocatePool (sizeof (MNP_TX_BUF_WRAP) +
MnpDeviceData->BufferLength - 1);
+if (TxBufWrap == NULL) {
+ DEBUG ((EFI_D_ERROR, "MnpAddFreeTxBuf: TxBuf Alloc failed.\n"));
+
+ Status = EFI_OUT_OF_RESOURCES;
+ break;
+}
+DEBUG ((EFI_D_INFO, "MnpAddFreeTxBuf: Add TxBufWrap %p, TxBuf %p\n",
TxBufWrap, TxBufWrap->TxBuf));
+TxBufWrap->Signature = MNP_TX_BUF_WRAP_SIGNATURE;
+TxBufWrap->InUse = FALSE;
+InsertTailList (&MnpDeviceData->FreeTxBufList, &TxBufWrap->WrapEntry);
+InsertTailList (&MnpDeviceData->AllTxBufList,
+ &TxBufWrap->AllEntry); }
+
+ MnpDeviceData->TxBufCount += Index;
+ return Status;
+}
+
+/**
+ Allocate a free TX buffer from MnpDeviceData->FreeTxBufList. If there
+is none
+ in the queue, first try to recycle some from SNP, then try to
+allocate some and add
+ them into the queue, then fetch the NET_BUF from the updated FreeTxBufList.
+
+ @param[in, out] MnpDeviceDataPointer to the MNP_DEVICE_DATA.
+
+ @return Pointer to the allocated free NET_BUF structure, if NULL the
+ operation is failed.
+
+**/
+UINT8 *
+MnpAllocTxBuf (
+ IN OUT MNP_DEVICE_DATA *MnpDeviceData
+ )
+{
+ EFI_TPL OldTpl;
+ UINT8 *TxBuf;
+ EFI_STATUSStatus;
+ LIST_ENTRY*Entry;
+ MNP_TX_BUF_WRAP *TxBufWrap;
+
+ NET_CHECK_SIGNATURE (MnpDeviceData, MNP_DEVICE_DATA_SIGNATURE);
+
+ OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
+
+
Re: [edk2] [PATCH] NetworkPkg: DnsDxe: fix return type of DnsFillinQNameForQueryIp()
Hi Laszlo, The patch is good to me. Reviewed-by: Jiaxin Wu Do you need my help to commit this one or by yourself? Thanks. Jiaxin -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, January 6, 2016 4:30 AM To: edk2-de...@ml01.01.org Cc: Subramanian Sriram; El-Haj-Mahmoud Samer; Ye, Ting; Fu, Siyuan; Wu, Jiaxin Subject: [PATCH] NetworkPkg: DnsDxe: fix return type of DnsFillinQNameForQueryIp() Change the return type of DnsFillinQNameForQueryIp() from (UINT8*) to (CHAR*). This brings the function in sync with both its internal variables and all of its call sites, fixing the following gcc build breakage: > NetworkPkg/DnsDxe/DnsImpl.c: In function 'DnsFillinQNameForQueryIp': > NetworkPkg/DnsDxe/DnsImpl.c:1068:3: error: pointer targets in return > differ in signedness > [-Werror=pointer-sign] >return QueryName; >^ The code was added in git commit fcae1a99 (SVN r19579). Cc: Subramanian Sriram Cc: El-Haj-Mahmoud Samer Cc: Ye Ting Cc: Fu Siyuan Cc: Jiaxin Wu Cc: Ye Ting Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- NetworkPkg/DnsDxe/DnsImpl.h | 2 +- NetworkPkg/DnsDxe/DnsImpl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NetworkPkg/DnsDxe/DnsImpl.h b/NetworkPkg/DnsDxe/DnsImpl.h index a13355f..847cd15 100644 --- a/NetworkPkg/DnsDxe/DnsImpl.h +++ b/NetworkPkg/DnsDxe/DnsImpl.h @@ -581,7 +581,7 @@ AddDns6ServerIp ( @return QName filled successfully. **/ -UINT8 * +CHAR8 * EFIAPI DnsFillinQNameForQueryIp ( IN CHAR16 *HostName diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c index 8725670..362af86 100644 --- a/NetworkPkg/DnsDxe/DnsImpl.c +++ b/NetworkPkg/DnsDxe/DnsImpl.c @@ -1026,7 +1026,7 @@ AddDns6ServerIp ( @return QName filled successfully. **/ -UINT8 * +CHAR8 * EFIAPI DnsFillinQNameForQueryIp ( IN CHAR16 *HostName -- 1.8.3.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] Nt32Pkg: Fix SnpNt32 GetStatus bug
Reviewed-by: Jiaxin Wu
> -Original Message-
> From: Zhang, Lubo
> Sent: Friday, April 29, 2016 10:09 AM
> To: Fu, Siyuan ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: RE: [edk2] [patch] Nt32Pkg: Fix SnpNt32 GetStatus bug
>
> A good comment to me, I will change it at the commit time, thanks
>
> -Original Message-
> From: Fu, Siyuan
> Sent: Friday, April 29, 2016 10:04 AM
> To: Zhang, Lubo ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: RE: [edk2] [patch] Nt32Pkg: Fix SnpNt32 GetStatus bug
>
> Hi, Lubo
>
> The allocate memory in SnpNt32InitializeGlobalData is better to use
> AllocatePool (sizeof (UINT64) * This->MaxRecycledTxBuf); to avoid
> possible macro value update in future.
> Other parts are good to me.
>
>
> Reviewed-by: Fu Siyuan
>
>
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Zhang Lubo
> > Sent: Friday, April 29, 2016 9:50 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ;
> > Wu, Jiaxin
> > Subject: [edk2] [patch] Nt32Pkg: Fix SnpNt32 GetStatus bug
> >
> > According to UEFI spec, the Snp.GetStatus should return the recycled
> > transmit buffer address, while the NT32 SNP always return value 1 for
> > the Txbuffer.
> >
> > Cc: Fu Siyuan
> > Cc: Ye Ting
> > Cc: Wu Jiaxin
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Zhang Lubo
> > ---
> > Nt32Pkg/SnpNt32Dxe/SnpNt32.c | 42
> > --
> > Nt32Pkg/SnpNt32Dxe/SnpNt32.h | 22 +-
> > 2 files changed, 61 insertions(+), 3 deletions(-)
> >
> > diff --git a/Nt32Pkg/SnpNt32Dxe/SnpNt32.c
> > b/Nt32Pkg/SnpNt32Dxe/SnpNt32.c index 4dee182..6d22c2f 100644
> > --- a/Nt32Pkg/SnpNt32Dxe/SnpNt32.c
> > +++ b/Nt32Pkg/SnpNt32Dxe/SnpNt32.c
> > @@ -1,8 +1,8 @@
> > /** @file
> >
> > -Copyright (c) 2006 - 2013, Intel Corporation. All rights
> > reserved.
> > +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
> >
> > @@ -42,10 +42,13 @@ SNPNT32_GLOBAL_DATA gSnpNt32GlobalData
> = {
> >{
> > 0,
> > 0,
> > EfiLockUninitialized
> >}, // Lock
> > + NULL, // RecycledTxBuf
> > + 0, // RecycledTxBufCount
> > + 32, // MaxRecycledTxBuf
> >//
> >// Private functions
> >//
> >SnpNt32InitializeGlobalData,// InitializeGlobalData
> >SnpNt32InitializeInstanceData, // InitializeInstanceData
> > @@ -859,13 +862,24 @@ SnpNt32GetStatus (
> >IN EFI_SIMPLE_NETWORK_PROTOCOL *This,
> >OUT UINT32 *InterruptStatus,
> >OUT VOID **TxBuffer
> >)
> > {
> > + SNPNT32_INSTANCE_DATA *Instance;
> > + SNPNT32_GLOBAL_DATA *GlobalData;
> > +
> > + Instance= SNP_NT32_INSTANCE_DATA_FROM_SNP_THIS (This);
> > +
> > + GlobalData = Instance->GlobalData;
> >
> >if (TxBuffer != NULL) {
> > -*((UINT8 **) TxBuffer) = (UINT8 *)(UINTN) 1;
> > +if (GlobalData->RecycledTxBufCount != 0) {
> > + GlobalData->RecycledTxBufCount --;
> > + *((UINT8 **) TxBuffer)= (UINT8 *) (UINTN)GlobalData-
> > >RecycledTxBuf[GlobalData->RecycledTxBufCount];
> > +} else {
> > + *((UINT8 **) TxBuffer)= NULL;
> > +}
> >}
> >
> >if (InterruptStatus != NULL) {
> > *InterruptStatus = EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT;
> >}
> > @@ -916,10 +930,11 @@ SnpNt32Transmit (
> >)
> > {
> >SNPNT32_INSTANCE_DATA *Instance;
> >SNPNT32_GLOBAL_DATA *GlobalData;
> >INT32 ReturnValue;
> > + UINT64*Tmp;
> >
> >Instance= SNP_NT32_INSTANCE_DATA_FROM_SNP_THIS (This);
> >
> >GlobalData = Instance->GlobalData;
> >
> > @@ -943,10 +958,28 @@ SnpNt32Transmit (
> >
> >EfiReleaseLock (&GlobalData->Lock);
> >
> >if (ReturnValue < 0) {
> > return EF
Re: [edk2] [Patch 0/2] Do not use hard coded TTL/ToS in PXE driver.
Series Reviewed-By: Wu Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu > Siyuan > Sent: Tuesday, May 3, 2016 10:26 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch 0/2] Do not use hard coded TTL/ToS in PXE driver. > > EFI_PXE_BASE_CODE_PROTOCOL has interface to set the TTL and ToS value, > but not used by the UdpWrite() interface. The code always use a hard coded > 16 for the TTL and 0 for ToS. > This patch update the UpdWrite() to use the TTL and ToS which have been > set by the SetParameters(). > > Fu Siyuan (2): > NetworkPkg: Do not use hard coded TTL/ToS in PXE driver. > MdeModulePkg: Do not use hard coded TTL/ToS in PXE driver. > > .../Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 6 -- > .../Universal/Network/UefiPxeBcDxe/PxeBcSupport.c | 12 > .../Universal/Network/UefiPxeBcDxe/PxeBcSupport.h | 14 +- > NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c| 6 -- > NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c | 12 > NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h | 22 + > - > 6 files changed, 46 insertions(+), 26 deletions(-) > > -- > 2.7.4.windows.1 > > ___ > 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] [Patch 0/2] 0001-NetworkPkg-Ignore-BootFileName-if-it-is-overloaded
Series Reviewed-By: Wu Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu > Siyuan > Sent: Tuesday, May 3, 2016 1:36 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch 0/2] 0001-NetworkPkg-Ignore-BootFileName-if-it-is- > overloaded > > > Fu Siyuan (2): > NetworkPkg: Ignore BootFileName if it is overloaded. > NetworkPkg: Ignore BootFileName if it is overloaded. > > NetworkPkg/HttpBootDxe/HttpBootDhcp4.c | 5 - > NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c | 7 +-- > 2 files changed, 9 insertions(+), 3 deletions(-) > > -- > 2.7.4.windows.1 > > ___ > 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] [PATCH v1 1/1] MdeModulePkg:DxeHttpLib: Add checks in HttpGenRequestMessage API
Hi Nagaraj,
Constructing header parts seems should be outside the conditional of "if
(Message->Data.Request != NULL)".
if (HttpHdr != NULL) {
//
// Construct header
//
CopyMem (RequestPtr, HttpHdr, HttpHdrSize);
RequestPtr += HttpHdrSize;
}
Others is good to me.
Reviewed-By: Wu Jiaxin
Thanks.
Jiaxin
> -Original Message-
> From: Nagaraj Hegde [mailto:nagaraj-p.he...@hpe.com]
> Sent: Wednesday, May 4, 2016 5:33 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Fu, Siyuan ; Ye,
> Ting ; samer.el-haj-mahm...@hpe.com
> Subject: [PATCH v1 1/1] MdeModulePkg:DxeHttpLib: Add checks in
> HttpGenRequestMessage API
>
> HttpGenRequestMessage assumes that HTTP message would always contain
> a request-line, headers and an optional message body.
> However, subsequent to a HTTP PUT/POST request, HTTP requests would
> contain just the message body. This patch supports creation of such request
> messages with additional checks.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hegde, Nagaraj P nagaraj-p.he...@hpe.com
> ---
> MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 219 +++---
> --
> 1 file changed, 124 insertions(+), 95 deletions(-)
>
> diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> index 8d61d0b..fa0f591 100644
> --- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> +++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> @@ -1681,61 +1681,86 @@ HttpGenRequestMessage (
>HttpUtilitiesProtocol = NULL;
>
>//
> - // Locate the HTTP_UTILITIES protocol.
> + // If we have a Request, we cannot have a NULL Url
>//
> - Status = gBS->LocateProtocol (
> - &gEfiHttpUtilitiesProtocolGuid,
> - NULL,
> - (VOID **)&HttpUtilitiesProtocol
> - );
> -
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR,"Failed to locate Http Utilities protocol. Status
> = %r.\n", Status));
> -return Status;
> + if (Message->Data.Request != NULL && Url == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
> + if (Message->HeaderCount != 0) {
> +//
> +// Locate the HTTP_UTILITIES protocol.
> +//
> +Status = gBS->LocateProtocol (
> +&gEfiHttpUtilitiesProtocolGuid,
> +NULL,
> +(VOID **)&HttpUtilitiesProtocol
> +);
> +
> +if (EFI_ERROR (Status)) {
> + DEBUG ((DEBUG_ERROR,"Failed to locate Http Utilities protocol. Status
> = %r.\n", Status));
> + return Status;
> +}
> +
> +//
> +// Build AppendList to send into HttpUtilitiesBuild
> +//
> +AppendList = AllocateZeroPool (sizeof (EFI_HTTP_HEADER *) * (Message-
> >HeaderCount));
> +if (AppendList == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +
> +for(Index = 0; Index < Message->HeaderCount; Index++){
> + AppendList[Index] = &Message->Headers[Index];
> +}
> +
> +//
> +// Build raw HTTP Headers
> +//
> +Status = HttpUtilitiesProtocol->Build (
> +HttpUtilitiesProtocol,
> +0,
> +NULL,
> +0,
> +NULL,
> +Message->HeaderCount,
> +AppendList,
> +&HttpHdrSize,
> +&HttpHdr
> +);
> +
> +if (AppendList != NULL) {
> + FreePool (AppendList);
> +}
> +
> +if (EFI_ERROR (Status) || HttpHdr == NULL){
> + return Status;
> +}
>}
>
>//
> - // Build AppendList to send into HttpUtilitiesBuild
> + // If we have headers to be sent, account for it.
>//
> - AppendList = AllocateZeroPool (sizeof (EFI_HTTP_HEADER *) * (Message-
> >HeaderCount));
> - if (AppendList == NULL) {
> -return EFI_OUT_OF_RESOURCES;
> - }
> -
> - for(Index = 0; Index < Message->HeaderCount; Index++){
> -AppendList[Index] = &Message->Headers[Index];
> + if (Message->HeaderCount != 0) {
> +MsgSize = HttpHdrSize;
>}
>
>//
> - // Build raw HTTP Headers
> + // If we have a request line, account for the fields.
>//
> - Status = HttpUtilitiesProtocol->Build (
> - HttpUtilitiesProtocol,
> - 0,
> - NULL,
> - 0,
> - NULL,
> - Message->HeaderCount,
> - AppendList,
> - &HttpHdrSize,
> - &Http
Re: [edk2] [PATCH v1 1/1] MdeModulePkg:DxeHttpLib: Add checks in HttpGenRequestMessage API
Yeah, according UEFI Spec, in my understanding, only two extra cases are
allowed:
A. Body is not NULL and BodyLength is non-zero and all other fields are NULL or
0 (POST and PUT methods, depending on the size of the data)
B. Body is NULL and BodyLength is 0 and all other fields are not NULL or
non-zero (Not POST or PUT method)
If so, keep this condition inside is ok, how about we update the below piece
code:
"if (Message->Data.Request != NULL && Url == NULL) {
return EFI_INVALID_PARAMETER;
}"
To:
"if ((Message->Data.Request != NULL && Url == NULL) || (Message->Data.Request
!= NULL && Message->HeaderCount == 0)) {
return EFI_INVALID_PARAMETER;
}"
Thanks.
Jiaxin
> -Original Message-
> From: Hegde, Nagaraj P [mailto:nagaraj-p.he...@hpe.com]
> Sent: Thursday, May 5, 2016 11:48 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting ; El-Haj-
> Mahmoud, Samer
> Subject: RE: [PATCH v1 1/1] MdeModulePkg:DxeHttpLib: Add checks in
> HttpGenRequestMessage API
>
> Hi Jiaxin,
>
> I believe in HTTP 1.1, servers do not accept Request methods without any
> header. In other words, "Host:" header is a must for all request methods.
> That was the reason I planned to put the construction of header parts inside
> the "if (Message->Data.Request != NULL" condition. Now, I wonder if we
> need to add this condition in the entry of this function itself and return a
> EFI_INVALID_PARAMETER or allow it to go to HTTP server and return back as
> "400 Bad Request". In case we allow, I see an issue. We would miss sending
> the additional "\r\n" which would mark the end of request and headers (if
> any). Adding additional "\r\n" is embedded into HttpUtilities Build function.
>
> Regards,
> Nagaraj.
>
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Thursday, May 05, 2016 8:10 AM
> To: Hegde, Nagaraj P ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting ; El-Haj-
> Mahmoud, Samer
> Subject: RE: [PATCH v1 1/1] MdeModulePkg:DxeHttpLib: Add checks in
> HttpGenRequestMessage API
>
> Hi Nagaraj,
>
> Constructing header parts seems should be outside the conditional of "if
> (Message->Data.Request != NULL)".
>
> if (HttpHdr != NULL) {
> //
> // Construct header
> //
> CopyMem (RequestPtr, HttpHdr, HttpHdrSize);
> RequestPtr += HttpHdrSize;
> }
>
> Others is good to me.
>
> Reviewed-By: Wu Jiaxin
>
> Thanks.
> Jiaxin
>
> > -Original Message-
> > From: Nagaraj Hegde [mailto:nagaraj-p.he...@hpe.com]
> > Sent: Wednesday, May 4, 2016 5:33 PM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Jiaxin ; Fu, Siyuan
> > ; Ye, Ting ;
> > samer.el-haj-mahm...@hpe.com
> > Subject: [PATCH v1 1/1] MdeModulePkg:DxeHttpLib: Add checks in
> > HttpGenRequestMessage API
> >
> > HttpGenRequestMessage assumes that HTTP message would always
> contain a
> > request-line, headers and an optional message body.
> > However, subsequent to a HTTP PUT/POST request, HTTP requests would
> > contain just the message body. This patch supports creation of such
> > request messages with additional checks.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Hegde, Nagaraj P nagaraj-p.he...@hpe.com
> > ---
> > MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 219 +++-
> --
> > --
> > 1 file changed, 124 insertions(+), 95 deletions(-)
> >
> > diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> > b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> > index 8d61d0b..fa0f591 100644
> > --- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> > +++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> > @@ -1681,61 +1681,86 @@ HttpGenRequestMessage (
> >HttpUtilitiesProtocol = NULL;
> >
> >//
> > - // Locate the HTTP_UTILITIES protocol.
> > + // If we have a Request, we cannot have a NULL Url
> >//
> > - Status = gBS->LocateProtocol (
> > - &gEfiHttpUtilitiesProtocolGuid,
> > - NULL,
> > - (VOID **)&HttpUtilitiesProtocol
> > - );
> > -
> > - if (EFI_ERROR (Status)) {
> > -DEBUG ((DEBUG_ERROR,"Failed to locate Http Utilities protocol. Status
> > = %r.\n", Status));
> > -return Status;
> > + if (Message->Data.Request != NULL && Url == NULL) {
> > +return EFI_INVALID_PARAMETER;
> > + }
> > +
> > +
Re: [edk2] [PATCH v2] MdeModulePkg: Refine SNP driver's media status check logic.
Reviewed-By: Wu Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Wednesday, May 4, 2016 4:48 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: [PATCH v2] MdeModulePkg: Refine SNP driver's media status check
> logic.
>
> V2 Update:
> Refine variable and function description per Ye, Ting's comments.
>
> Some UNDI drivers may not support the cable detect in UNDI INITIALIZE
> command, but support the media present check in UNDI GET_STATUS
> command. Current SNP driver will set the MediaPresentSupported field to
> FALSE in EFI_SIMPLE_NETWORK_MODE for such case, which forbid the
> media detect from the callers.
>
> This patch updates the SNP driver to support such kind of UNDIs for media
> detect.
> MediaPresentSupported will be set to TRUE, and a GET_STATUS command
> will be issued immediately after INITIALIZE command in SNP->Initialize()
> function, to refresh the value of MediaPresent in SNP mode data.
>
> Cc: Ye Ting
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan
> ---
> MdeModulePkg/Universal/Network/SnpDxe/Get_status.c | 25 --
> -- MdeModulePkg/Universal/Network/SnpDxe/Initialize.c | 13
> -
> MdeModulePkg/Universal/Network/SnpDxe/Snp.c| 8 +++--
> MdeModulePkg/Universal/Network/SnpDxe/Snp.h| 34
> +-
> 4 files changed, 64 insertions(+), 16 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
> b/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
> index edbc0f2..4c3bdae 100644
> --- a/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
> +++ b/MdeModulePkg/Universal/Network/SnpDxe/Get_status.c
> @@ -18,24 +18,25 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> /**
>Call undi to get the status of the interrupts, get the list of recycled
> transmit
>buffers that completed transmitting. The recycled transmit buffer address
> will
> - be saved into Snp->RecycledTxBuf.
> + be saved into Snp->RecycledTxBuf. This function will also update the
> + MediaPresent field of EFI_SIMPLE_NETWORK_MODE if UNDI support it.
>
> - @param Snp Pointer to snp driver structure.
> - @param InterruptStatusPtr A non null pointer to contain the interrupt
> - status.
> - @param GetTransmittedBuf Set to TRUE to retrieve the recycled
> transmit
> - buffer address.
> + @param[in] Snp Pointer to snp driver structure.
> + @param[out] InterruptStatusPtr A non null pointer to contain the
> interrupt
> + status.
> + @param[in] GetTransmittedBuf Set to TRUE to retrieve the recycled
> transmit
> + buffer address.
>
> - @retval EFI_SUCCESS The status of the network interface was
> retrieved.
> - @retval EFI_DEVICE_ERRORThe command could not be sent to the
> network
> - interface.
> + @retval EFI_SUCCESS The status of the network interface
> was
> retrieved.
> + @retval EFI_DEVICE_ERRORThe command could not be sent to the
> network
> + interface.
>
> **/
> EFI_STATUS
> PxeGetStatus (
> - SNP_DRIVER *Snp,
> - UINT32 *InterruptStatusPtr,
> - BOOLEANGetTransmittedBuf
> + IN SNP_DRIVER *Snp,
> + OUT UINT32 *InterruptStatusPtr,
> + IN BOOLEANGetTransmittedBuf
>)
> {
>PXE_DB_GET_STATUS *Db;
> diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> index 3f40ef3..2151375 100644
> --- a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> +++ b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> @@ -229,7 +229,10 @@ SnpUndi32Initialize (
>//
>Snp->TxRxBufferSize = (UINT32) (Snp->InitInfo.MemoryRequired +
> ExtraRxBufferSize + ExtraTxBufferSize);
>
> - if (Snp->Mode.MediaPresentSupported) {
> + //
> + // If UNDI support cable detect for INITIALIZE command, try it first.
> + //
> + if (Snp->CableDetectSupported) {
> if (PxeInit (Snp, PXE_OPFLAGS_INITIALIZE_DETECT_CABLE) ==
> EFI_SUCCESS) {
>Snp->Mode.MediaPresent = TRUE;
>goto ON_EXIT;
> @@ -242,6 +245,14 @@ SnpUndi32Initialize (
>
>if (EFI_ERROR (EfiStatus)) {
> gBS->CloseEvent (Snp->Snp.WaitForPacket);
> +goto ON_EXIT;
> + }
> +
> + //
> + // Try to update the MediaPresent field of EFI_SI
Re: [edk2] [Patch] NetworkPkg: Fix a memory leak in HTTP boot driver.
The patch is good to me.
Reviewed-By: Wu Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Thursday, May 5, 2016 10:16 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: [Patch] NetworkPkg: Fix a memory leak in HTTP boot driver.
>
> We always need to call EfiBootManagerFreeLoadOption because the
> memory allocated for NewOption (description and device path) is no longer
> needed.
>
> Cc: Ye Ting
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan
> ---
> NetworkPkg/HttpBootDxe/HttpBootConfig.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> index 2ca38b5..04c2f3e 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> @@ -142,9 +142,7 @@ HttpBootAddBootOption (
>}
>
>Status = EfiBootManagerAddLoadOptionVariable (&NewOption, (UINTN) -
> 1);
> - if (EFI_ERROR (Status)) {
> -EfiBootManagerFreeLoadOption (&NewOption);
> - }
> + EfiBootManagerFreeLoadOption (&NewOption);
>
> ON_EXIT:
>
> --
> 2.7.4.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/1] NetworkPkg:HttpDxe: Code changes to support HTTP PUT/POST operations
Hi Nagaraj,
In every EfiHttpRequest() for PUT/POST, HttpInitTcp() will be called even the
TCP state is established (get from TCP4/6 GetModeData each time) and return
EFI_SUCCESS.
To avoid this repeating function call and improve the performance, we can check
the current Http state, if required, then call it:
if (HttpInstance->State != HTTP_STATE_TCP_CONNECTED) {
Status = HttpInitTcp (HttpInstance, Wrap, Configure);
if (EFI_ERROR (Status)) {
goto Error2;
}
}
Others is good to me.
Reviewed-By: Wu Jiaxin
Thanks.
Jiaxin
> -Original Message-
> From: Nagaraj Hegde [mailto:nagaraj-p.he...@hpe.com]
> Sent: Friday, May 6, 2016 6:20 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Fu, Siyuan ; Ye,
> Ting ; samer.el-haj-mahm...@hpe.com
> Subject: [PATCH v2 1/1] NetworkPkg:HttpDxe: Code changes to support
> HTTP PUT/POST operations
>
> v2: Add comments for the code changes.
>
> Code changes enables HttpDxe to handle PUT/POST operations.
> EfiHttpRequest assumes "Request" and "HttpMsg->Headers" can never be
> NULL. Also, HttpResponseWorker assumes HTTP Reponse will contain
> headers. We could have response which could contain only a string (HTTP 100
> Continue) and no headers. Code changes tries to do-away from these
> assumptions, which would enable HttpDxe to support PUT/POST operations.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hegde, Nagaraj P nagaraj-p.he...@hpe.com
> ---
> NetworkPkg/HttpDxe/HttpDriver.c | 3 +
> NetworkPkg/HttpDxe/HttpImpl.c | 445
> NetworkPkg/HttpDxe/HttpProto.h | 1 +
> 3 files changed, 264 insertions(+), 185 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.c
> b/NetworkPkg/HttpDxe/HttpDriver.c index 2518f4e..da6d087 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.c
> +++ b/NetworkPkg/HttpDxe/HttpDriver.c
> @@ -2,6 +2,7 @@
>The driver binding and service binding protocol for HttpDxe driver.
>
>Copyright (c) 2015, 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 @@ -939,6 +940,8 @@ HttpServiceBindingCreateChild (
>
>HttpInstance->Signature = HTTP_PROTOCOL_SIGNATURE;
>HttpInstance->Service = HttpService;
> + HttpInstance->Method = HttpMethodMax;
> +
>CopyMem (&HttpInstance->Http, &mEfiHttpTemplate, sizeof
> (HttpInstance->Http));
>NetMapInit (&HttpInstance->TxTokens);
>NetMapInit (&HttpInstance->RxTokens); diff --git
> a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
> index 7a236f4..9bc0f8a 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -248,151 +248,185 @@ EfiHttpRequest (
>HTTP_TOKEN_WRAP *Wrap;
>CHAR8 *FileUrl;
>UINTN RequestMsgSize;
> -
> +
> + //
> + // Initializations
> + //
> + Url = NULL;
> + HostName = NULL;
> + RequestMsg = NULL;
> + HostNameStr = NULL;
> + Wrap = NULL;
> + FileUrl = NULL;
> +
>if ((This == NULL) || (Token == NULL)) {
> return EFI_INVALID_PARAMETER;
>}
>
>HttpMsg = Token->Message;
> - if ((HttpMsg == NULL) || (HttpMsg->Headers == NULL)) {
> + if (HttpMsg == NULL) {
> return EFI_INVALID_PARAMETER;
>}
>
> - //
> - // Current implementation does not support POST/PUT method.
> - // If future version supports these two methods, Request could be NULL
> for a special case that to send large amounts
> - // of data. For this case, the implementation need check whether previous
> call to Request() has been completed or not.
> - //
> - //
>Request = HttpMsg->Data.Request;
> - if ((Request == NULL) || (Request->Url == NULL)) {
> -return EFI_INVALID_PARAMETER;
> - }
>
>//
> - // Only support GET and HEAD method in current implementation.
> + // Only support GET, HEAD, PUT and POST method in current
> implementation.
>//
> - if ((Request->Method != HttpMethodGet) && (Request->Method !=
> HttpMethodHead)) {
> + if ((Request != NULL) && (Request->Method != HttpMethodGet) &&
> + (Request->Method != HttpMethodHead) && (Request->Method !=
> + HttpMethodPut) && (Request->Method != HttpMethodPost)) {
> return EFI_UNSUPPORTED;
>}
>
>HttpInstance = HTTP_INSTANCE_FROM_PROTOCOL (This);
>ASSERT (HttpInstance != NULL);
>
> + //
> + //
Re: [edk2] [PATCH v2 1/1] MdeModulePkg:DxeHttpLib: Add checks in HttpGenRequestMessage API
It's good to me!
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Nagaraj Hegde
> Sent: Thursday, May 5, 2016 2:59 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [edk2] [PATCH v2 1/1] MdeModulePkg:DxeHttpLib: Add checks in
> HttpGenRequestMessage API
>
> v2:
> More input validation based on Request and HeaderCount.
>
> HttpGenRequestMessage assumes that HTTP message would always contain
> a request-line, headers and an optional message body.
> However, subsequent to a HTTP PUT/POST request, HTTP requests would
> contain just the message body. This patch supports creation of such request
> messages with additional checks.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hegde, Nagaraj P nagaraj-p.he...@hpe.com
> ---
> MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 225 +++---
> --
> 1 file changed, 130 insertions(+), 95 deletions(-)
>
> diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> index 8d61d0b..1b0858c 100644
> --- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> +++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> @@ -1681,61 +1681,92 @@ HttpGenRequestMessage (
>HttpUtilitiesProtocol = NULL;
>
>//
> - // Locate the HTTP_UTILITIES protocol.
> + // 1. If we have a Request, we cannot have a NULL Url // 2. If we
> + have a Request, HeaderCount can not be non-zero // 3. If we do not
> + have a Request, HeaderCount should be zero // 4. If we do not have
> + Request and Headers, we need at least a message-body
>//
> - Status = gBS->LocateProtocol (
> - &gEfiHttpUtilitiesProtocolGuid,
> - NULL,
> - (VOID **)&HttpUtilitiesProtocol
> - );
> -
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR,"Failed to locate Http Utilities protocol. Status
> = %r.\n", Status));
> -return Status;
> + if ((Message->Data.Request != NULL && Url == NULL) ||
> + (Message->Data.Request != NULL && Message->HeaderCount == 0) ||
> + (Message->Data.Request == NULL && Message->HeaderCount != 0) ||
> + (Message->Data.Request == NULL && Message->HeaderCount == 0 &&
> Message->BodyLength == 0)) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
> + if (Message->HeaderCount != 0) {
> +//
> +// Locate the HTTP_UTILITIES protocol.
> +//
> +Status = gBS->LocateProtocol (
> +&gEfiHttpUtilitiesProtocolGuid,
> +NULL,
> +(VOID **)&HttpUtilitiesProtocol
> +);
> +
> +if (EFI_ERROR (Status)) {
> + DEBUG ((DEBUG_ERROR,"Failed to locate Http Utilities protocol. Status
> = %r.\n", Status));
> + return Status;
> +}
> +
> +//
> +// Build AppendList to send into HttpUtilitiesBuild
> +//
> +AppendList = AllocateZeroPool (sizeof (EFI_HTTP_HEADER *) * (Message-
> >HeaderCount));
> +if (AppendList == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +
> +for(Index = 0; Index < Message->HeaderCount; Index++){
> + AppendList[Index] = &Message->Headers[Index];
> +}
> +
> +//
> +// Build raw HTTP Headers
> +//
> +Status = HttpUtilitiesProtocol->Build (
> +HttpUtilitiesProtocol,
> +0,
> +NULL,
> +0,
> +NULL,
> +Message->HeaderCount,
> +AppendList,
> +&HttpHdrSize,
> +&HttpHdr
> +);
> +
> +if (AppendList != NULL) {
> + FreePool (AppendList);
> +}
> +
> +if (EFI_ERROR (Status) || HttpHdr == NULL){
> + return Status;
> +}
>}
>
>//
> - // Build AppendList to send into HttpUtilitiesBuild
> + // If we have headers to be sent, account for it.
>//
> - AppendList = AllocateZeroPool (sizeof (EFI_HTTP_HEADER *) * (Message-
> >HeaderCount));
> - if (AppendList == NULL) {
> -return EFI_OUT_OF_RESOURCES;
> - }
> -
> - for(Index = 0; Index < Message->HeaderCount; Index++){
> -AppendList[Index] = &Message->Headers[Index];
> + if (Message->HeaderCount != 0) {
> +MsgSize = HttpHdrSize;
>}
>
>//
> - // Build raw HTTP Headers
> + // If we have a request line, account for the fields
Re: [edk2] [PATCH] NetworkPkg: Make HttpBootGetBootFile return EFI_BUFFER_TOO_SMALL
Looks good to me.
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Monday, May 9, 2016 12:33 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin
> Subject: [PATCH] NetworkPkg: Make HttpBootGetBootFile return
> EFI_BUFFER_TOO_SMALL
>
> Per the description of HttpBootGetBootFile, the function should return
> EFI_BUFFER_TOO_SMALL if the given buffer is smaller than the remote
> image.
>
> Cc: Siyuan Fu
> Cc: Jiaxin Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gary Lin
> ---
> NetworkPkg/HttpBootDxe/HttpBootClient.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c
> b/NetworkPkg/HttpBootDxe/HttpBootClient.c
> index 9d445e3..46cf9ca 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
> @@ -1074,6 +1074,8 @@ HttpBootGetBootFile (
>
>if (*BufferSize < ContentLength) {
> Status = EFI_BUFFER_TOO_SMALL;
> + } else {
> +Status = EFI_SUCCESS;
>}
>*BufferSize = ContentLength;
>
> @@ -1089,7 +1091,7 @@ HttpBootGetBootFile (
> HttpFreeMsgParser (Parser);
>}
>
> - return EFI_SUCCESS;
> + return Status;
>
> ERROR_6:
>if (Parser != NULL) {
> --
> 2.8.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS indefinite poll case
Hi all,
Any comments for this patch?
Thanks.
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Wednesday, May 4, 2016 3:08 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Long,
> Qin
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
> indefinite poll case
>
> This patch is used to handle handle HTTPS indefinite poll case.
>
> Cc: El-Haj-Mahmoud Samer
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Long Qin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> NetworkPkg/HttpDxe/HttpImpl.c | 55 ++
> NetworkPkg/HttpDxe/HttpProto.c | 68
> ++
> 2 files changed, 93 insertions(+), 30 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index cf58b13..cd8fe05 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1179,47 +1179,50 @@ HttpResponseWorker (
> }
>}
>
>ASSERT (HttpInstance->MsgParser != NULL);
>
> - //
> - // We still need receive more data when there is no cache data and
> MsgParser is not NULL;
> - //
> - if (!HttpInstance->UseHttps) {
> -if (HttpInstance->TimeoutEvent == NULL) {
> - //
> - // Create TimeoutEvent for response
> - //
> - Status = gBS->CreateEvent (
> - EVT_TIMER,
> - TPL_CALLBACK,
> - NULL,
> - NULL,
> - &HttpInstance->TimeoutEvent
> - );
> - if (EFI_ERROR (Status)) {
> -goto Error;
> - }
> -}
> -
> + if (HttpInstance->TimeoutEvent == NULL) {
> //
> -// Start the timer, and wait Timeout seconds to receive the body packet.
> +// Create TimeoutEvent for response
> //
> -Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
> +Status = gBS->CreateEvent (
> +EVT_TIMER,
> +TPL_CALLBACK,
> +NULL,
> +NULL,
> +&HttpInstance->TimeoutEvent
> +);
> if (EFI_ERROR (Status)) {
>goto Error;
> }
> -
> + }
> +
> + //
> + // Start the timer, and wait Timeout seconds to receive the body packet.
> + //
> + Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> + HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND); if (EFI_ERROR (Status))
> {
> +goto Error;
> + }
> +
> + //
> + // We still need receive more data when there is no cache data and
> + MsgParser is not NULL; // if (!HttpInstance->UseHttps) {
> Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance-
> >TimeoutEvent);
>
> gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
>
> if (EFI_ERROR (Status)) {
>goto Error;
> }
>} else {
> -Status = HttpsReceive (HttpInstance, &Fragment, NULL);
> +Status = HttpsReceive (HttpInstance, &Fragment,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> +
> if (EFI_ERROR (Status)) {
>goto Error;
> }
>
> //
> @@ -1315,11 +1318,13 @@ Exit:
>
> Error2:
>NetMapInsertHead (&HttpInstance->TxTokens, ValueInItem->HttpToken,
> ValueInItem);
>
> Error:
> - HttpTcpTokenCleanup (Wrap);
> + if (!HttpInstance->UseHttps) {
> +HttpTcpTokenCleanup (Wrap);
> + }
>
>if (HttpHeaders != NULL) {
> FreePool (HttpHeaders);
> HttpHeaders = NULL;
>}
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c index 965a49f..ebb9dd9 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -1230,11 +1230,40 @@ HttpConnectTcp4 (
>
>//
>// Tls session connection.
>//
>if (HttpInstance->UseHttps) {
> -Status = TlsConnectSession (HttpInstance, NULL);
> +if (HttpInstance->TimeoutEvent == NULL) {
> + //
> + // Create TimeoutEvent for TLS connection.
> + //
> + Status = gBS->CreateEvent (
> + EVT_TIMER,
> + TPL_CALLBACK,
> + NULL,
> + NULL,
> + &HttpInstance->TimeoutEvent
> + );
> + if (EFI_ERROR (Status)) {
> +TlsCloseTxRxEvent (HttpInstance);
> +return Status;
> + }
> +}
> +
> +//
> +// Start the timer, and wait Timeout seconds for connection.
> +//
> +Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_CONNECTION_TIMEOUT * TICKS_PER_SECOND);
> +if (EFI_ERROR (Status)) {
> + TlsCloseTxRxEvent (HttpInstance);
> + return Status;
> +}
> +
> +Status = TlsConnectSession (HttpInstance,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->T
Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS indefinite poll case
Thanks Samer. /Jiaxin
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com]
Sent: Thursday, May 12, 2016 8:21 AM
To: edk2-devel@lists.01.org; Wu, Jiaxin
Cc: Ye, Ting ; Fu, Siyuan ; Long, Qin
Subject: RE: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
indefinite poll case
Sorry for the delay Jiaxin. I don't see issues with this. I did pull it into
our build and didn't find any regression.
Reviewed-by : Samer El-Haj-Mahmoud mailto:el...@hpe.com>>
-Original Message-
From: Wu, Jiaxin [jiaxin...@intel.com]
Received: Wednesday, 11 May 2016, 7:18PM
To: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com];
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
[edk2-devel@lists.01.org]
CC: Ye, Ting [ting...@intel.com]; Fu, Siyuan [siyuan...@intel.com]; Long, Qin
[qin.l...@intel.com]
Subject: RE: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
indefinite poll case
Hi all,
Any comments for this patch?
Thanks.
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Wednesday, May 4, 2016 3:08 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Ye, Ting mailto:ting...@intel.com>>; Fu, Siyuan
> mailto:siyuan...@intel.com>>; Long,
> Qin mailto:qin.l...@intel.com>>
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Handle HTTPS
> indefinite poll case
>
> This patch is used to handle handle HTTPS indefinite poll case.
>
> Cc: El-Haj-Mahmoud Samer
> mailto:samer.el-haj-mahm...@hpe.com>>
> Cc: Ye Ting mailto:ting...@intel.com>>
> Cc: Fu Siyuan mailto:siyuan...@intel.com>>
> Cc: Long Qin mailto:qin.l...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu mailto:jiaxin...@intel.com>>
> ---
> NetworkPkg/HttpDxe/HttpImpl.c | 55 ++
> NetworkPkg/HttpDxe/HttpProto.c | 68
> ++
> 2 files changed, 93 insertions(+), 30 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index cf58b13..cd8fe05 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1179,47 +1179,50 @@ HttpResponseWorker (
> }
>}
>
>ASSERT (HttpInstance->MsgParser != NULL);
>
> - //
> - // We still need receive more data when there is no cache data and
> MsgParser is not NULL;
> - //
> - if (!HttpInstance->UseHttps) {
> -if (HttpInstance->TimeoutEvent == NULL) {
> - //
> - // Create TimeoutEvent for response
> - //
> - Status = gBS->CreateEvent (
> - EVT_TIMER,
> - TPL_CALLBACK,
> - NULL,
> - NULL,
> - &HttpInstance->TimeoutEvent
> - );
> - if (EFI_ERROR (Status)) {
> -goto Error;
> - }
> -}
> -
> + if (HttpInstance->TimeoutEvent == NULL) {
> //
> -// Start the timer, and wait Timeout seconds to receive the body packet.
> +// Create TimeoutEvent for response
> //
> -Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
> +Status = gBS->CreateEvent (
> +EVT_TIMER,
> +TPL_CALLBACK,
> +NULL,
> +NULL,
> +&HttpInstance->TimeoutEvent
> +);
> if (EFI_ERROR (Status)) {
>goto Error;
> }
> -
> + }
> +
> + //
> + // Start the timer, and wait Timeout seconds to receive the body packet.
> + //
> + Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> + HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND); if (EFI_ERROR (Status))
> {
> +goto Error;
> + }
> +
> + //
> + // We still need receive more data when there is no cache data and
> + MsgParser is not NULL; // if (!HttpInstance->UseHttps) {
> Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance-
> >TimeoutEvent);
>
> gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
>
> if (EFI_ERROR (Status)) {
>goto Error;
> }
>} else {
> -Status = HttpsReceive (HttpInstance, &Fragment, NULL);
> +Status = HttpsReceive (HttpInstance, &Fragment,
> + HttpInstance->TimeoutEvent);
> +
> +gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> +
> if (EFI_ERROR (Status)) {
>goto Error;
> }
>
> //
> @@ -1315,11
Re: [edk2] [patch] NetworkPkg: Bug fix of iSCSI to support MPIO
Reviewed-By: Wu Jiaxin
> -Original Message-
> From: Zhang, Lubo
> Sent: Wednesday, May 11, 2016 9:38 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [patch] NetworkPkg: Bug fix of iSCSI to support MPIO
>
> If two attempts added on different NIC and enable MPIO attribute, then
> change the attempts order. If both two attempts succeed to connect the
> target,it should abort the later one in the order and uninstall
> ExtScsiPassThruProtocol Interface, But now it unistall it twice.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo
> ---
> NetworkPkg/IScsiDxe/IScsiDriver.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/NetworkPkg/IScsiDxe/IScsiDriver.c
> b/NetworkPkg/IScsiDxe/IScsiDriver.c
> index 12095cb..5a121ce 100644
> --- a/NetworkPkg/IScsiDxe/IScsiDriver.c
> +++ b/NetworkPkg/IScsiDxe/IScsiDriver.c
> @@ -863,14 +863,26 @@ IScsiStart (
> IScsiRemoveNic (ExistPrivate->Controller);
> if (ExistPrivate->Session != NULL) {
>IScsiSessionAbort (ExistPrivate->Session);
> }
>
> -Status = IScsiCleanDriverData (ExistPrivate);
> -if (EFI_ERROR (Status)) {
> - goto ON_ERROR;
> +if (ExistPrivate->DevicePath != NULL) {
> + Status = gBS->UninstallProtocolInterface (
> + ExistPrivate->ExtScsiPassThruHandle,
> + &gEfiDevicePathProtocolGuid,
> + ExistPrivate->DevicePath
> + );
> + if (EFI_ERROR (Status)) {
> +goto ON_ERROR;
> + }
> +
> + FreePool (ExistPrivate->DevicePath);
> }
> +
> +gBS->CloseEvent (ExistPrivate->ExitBootServiceEvent);
> +FreePool (ExistPrivate);
> +
>}
> } else {
>//
>// Use the attempt in earlier order as boot selected in single path
> mode.
>//
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] HTTP Boot crashed when downloading remote image
Hi Lin, Thanks for your exposing. I haven't meet this crash yet. But, I will check this potential crash according your feedback. If any process, I will inform you. Thanks and Best Regards. Jiaxin > -Original Message- > From: Gary Lin [mailto:g...@suse.com] > Sent: Thursday, May 12, 2016 6:27 PM > To: edk2-devel@lists.01.org > Cc: Wu, Jiaxin > Subject: HTTP Boot crashed when downloading remote image > > Hi, > > I was testing HTTP Boot with the latest OMVF and found that it crashed when > downloading the remote image from the http server. Here is my bisect result: > > commit b347a22aecbfac9aac47831fee9a30aa810d6d0b > NetworkPkg: Avoid the indefinite wait case in HttpDxe > > Actually, it sometimes worked but was broken for the most of time. > Reverting this patch makes HTTP Boot always work. > > It seems the IP4 driver tried to remove a mnp event, but the event list was > empty so the assert was triggered. > > The debug message: > > TcpToSendAck: scheduled a delayed ACK for TCB 3E2D2418 > TcpToSendAck: scheduled a delayed ACK for TCB 3E2D2418 > TcpInput: sequence acceptance test failed for segment of TCB 3E2D2418 > TcpInput: Discard a packet > TcpInput: sequence acceptance test failed for segment of TCB 3E2D2418 > TcpInput: Discard a packet > TcpInput: sequence acceptance test failed for segment of TCB 3E2D2418 > TcpInput: Discard a packet > TcpInput: sequence acceptance test failed for segment of TCB 3E2D2418 > TcpInput: Discard a packet > ASSERT /home/gary/git/edk2/MdePkg/Library/BaseLib/LinkedList.c(62): List- > >BackLink != ((void *) 0) > > The backtrace (I cut the trace before EfiBootManagerBoot to make it > shorter): > > (gdb) bt > #0 0x3ff7f702 in CpuDeadLoop () at > /home/gary/git/edk2/MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x3ff80a34 in DebugAssert ( > FileName=0x3ff93b50 > "/home/gary/git/edk2/MdePkg/Library/BaseLib/LinkedList.c", > LineNumber=62, > Description=0x3ff93bb0 "List->BackLink != ((void *) 0)") > at > /home/gary/git/edk2/OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c > :153 > #2 0x3ff7f7e3 in InternalBaseLibIsNodeInList (List=0x3e2c40a0, > Node=0x3e2c40a0, > VerifyNodeInList=0 '\000') at > /home/gary/git/edk2/MdePkg/Library/BaseLib/LinkedList.c:62 > #3 0x3ff7fc49 in IsListEmpty (ListHead=0x3e2c40a0) > at /home/gary/git/edk2/MdePkg/Library/BaseLib/LinkedList.c:361 > #4 0x3ff7fec5 in RemoveEntryList (Entry=0x3e2c40a0) > at /home/gary/git/edk2/MdePkg/Library/BaseLib/LinkedList.c:545 > #5 0x3ff7a5e5 in CoreCloseEvent (UserEvent=0x3e2c4018) > at /home/gary/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:752 > #6 0x3e99a910 in Ip4FreeFrameRxToken (Token=0x3e2c4118) > at > /home/gary/git/edk2/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.c:38 > 0 > #7 0x3e99bdfe in Ip4RecycleFrame (Context=0x3e2c4118) > at > /home/gary/git/edk2/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.c:11 > 24 > #8 0x3e9b26db in NetbufFreeVector (Vector=0x3e2c4798) > at > /home/gary/git/edk2/MdeModulePkg/Library/DxeNetLib/NetBuffer.c:176 > #9 0x3e9b285e in NetbufFree (Nbuf=0x3e2c4698) > at > /home/gary/git/edk2/MdeModulePkg/Library/DxeNetLib/NetBuffer.c:220 > #10 0x3e9a39b6 in Ip4OnRecyclePacket (Event=0x3e2c4198, > Context=0x3e2c4398) > at > /home/gary/git/edk2/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Input. > c:1146 > #11 0x3ff79bd5 in CoreDispatchEventNotifies (Priority=16) > at /home/gary/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:200 > #12 0x3ff79179 in CoreRestoreTpl (NewTpl=8) at > /home/gary/git/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:131 > #13 0x3ff660e0 in CoreReleaseLock (Lock=0x3ff98990) > at /home/gary/git/edk2/MdeModulePkg/Core/Dxe/Library/Library.c:102 > #14 0x3ff7996b in CoreReleaseEventLock () at > /home/gary/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:119 > #15 0x3ff7a32c in CoreSignalEvent (UserEvent=0x3e2c4198) > at /home/gary/git/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:572 > #16 0x3e929c28 in IpIoExtFree (Event=0x3e2c4198) > at > /home/gary/git/edk2/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c:596 > #17 0x3e9307fb in NetbufFreeVector (Vector=0x3e2c4598) > at > /home/gary/git/edk2/MdeModulePkg/Library/DxeNetLib/NetBuffer.c:176 > #18 0x3e93097e in NetbufFree (Nbuf=0x3e2c4498) > at > /home/gary/git/edk2/MdeModulePkg/Library/DxeNetLib/NetBuffer.c:220 > #19 0x3e932551 in NetbufQueTrim (NbufQue=0x3e2d2698, > Len=59695) > at > /home/gary/git/edk2/MdeModulePkg/Library/DxeNetLib/NetBuffer.c:1605
Re: [edk2] HTTP Boot crashed when downloading remote image
Thanks Gary. We also found that if TCP CompletionToken is not signaled, it should not be closed directly by calling CloseEvent after timeout happened(Still in the TCP RcvTokenList). If not, any exception behavior may be triggered while more packets continue received but only timeout happened (do you root cause? I'm glad to know.). We should cancel it by calling Tcp4->Cancel(), then close it. but unfortunately, Tcp4->Cancel() is unsupported currently. Thanks. Jiaxin > -Original Message- > From: Gary Lin [mailto:g...@suse.com] > Sent: Thursday, May 19, 2016 10:06 AM > To: El-Haj-Mahmoud, Samer ; Laszlo > Ersek > Cc: edk2-devel@lists.01.org; Wu, Jiaxin > Subject: Re: [edk2] HTTP Boot crashed when downloading remote image > > On Wed, May 18, 2016 at 01:54:24PM +, El-Haj-Mahmoud, Samer wrote: > > Gary, > > > > The EDK2 list blocked the wireshark attachment. Can you put it on a share > and send a link please? We are trying to look at this internally as well. > Hi Samer and Laszlo, > > I've found the root cause. I'll send a patch later and Cc you guys. > > Thanks, > > Gary Lin > > > > > Thanks, > > --Samer > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Gary Lin > > Sent: Tuesday, May 17, 2016 11:29 PM > > To: edk2-devel@lists.01.org > > Cc: Jiaxin Wu > > Subject: Re: [edk2] HTTP Boot crashed when downloading remote image > > > > On Thu, May 12, 2016 at 06:26:36PM +0800, Gary Lin wrote: > > > Hi, > > > > > > I was testing HTTP Boot with the latest OMVF and found that it > > > crashed when downloading the remote image from the http server. Here > > > is my bisect result: > > > > > > commit b347a22aecbfac9aac47831fee9a30aa810d6d0b > > > NetworkPkg: Avoid the indefinite wait case in HttpDxe > > > > > > Actually, it sometimes worked but was broken for the most of time. > > > Reverting this patch makes HTTP Boot always work. > > > > > > It seems the IP4 driver tried to remove a mnp event, but the event > > > list was empty so the assert was triggered. > > > > > Some findings: > > > > 1. OVMF could crash without b347a22ae in a slight different way. > >Several "TcpInput: Discard a packet" showed without the assert. > > > > 2. Rx4Token->CompletionToken in HttpTcpReceiveBody() corrupted after > >the timeout. I saved Rx4Token->CompletionToken.Event before the > >loop of Tcp4->Poll() and set a assert like this: > > > >ASSERT(Rx4Token->CompletionToken.Event == event); > > > >right after "if (!Wrap->TcpWrap.IsRxDone)". The assert was raised > >after the timeout. > > > > 3. I attached wireshark to the tap interface. The first few packets were > >alright, and then the window size from ACK of OVMF decreased rapidly > >and "TCP ZeroWindow" showed right before the crash. I added debug > >message to HttpTcpReceiveNotify and found that the function wasn't > >triggered for some reason when the packets arrived and so > >Wrap->TcpWrap.IsRxDone was never set to TRUE. In the end, the socket > >RCVD buffer was used up, and then the timeout event triggered. > > > > I'll keep digging for more information. > > > > Thanks, > > > > Gary Lin > > > > > The debug message: > > > > > > TcpToSendAck: scheduled a delayed ACK for TCB 3E2D2418 > > > TcpToSendAck: scheduled a delayed ACK for TCB 3E2D2418 > > > TcpInput: sequence acceptance test failed for segment of TCB > > > 3E2D2418 > > > TcpInput: Discard a packet > > > TcpInput: sequence acceptance test failed for segment of TCB > > > 3E2D2418 > > > TcpInput: Discard a packet > > > TcpInput: sequence acceptance test failed for segment of TCB > > > 3E2D2418 > > > TcpInput: Discard a packet > > > TcpInput: sequence acceptance test failed for segment of TCB > > > 3E2D2418 > > > TcpInput: Discard a packet > > > ASSERT /home/gary/git/edk2/MdePkg/Library/BaseLib/LinkedList.c(62): > > > List->BackLink != ((void *) 0) > > > > > > The backtrace (I cut the trace before EfiBootManagerBoot to make it > > > shorter): > > > > > > (gdb) bt > > > #0 0x3ff7f702 in CpuDeadLoop () at > > > /home/gary/git/edk2/MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > > > #1 0x3ff80a34 in DebugAssert ( > > > F
Re: [edk2] edk2-staging/HTTPS-TLS
Hi all, There are two ways to sync HTTPS-TLS branch with EDK2 master: 1. Sync all changes in EDK2 master to branch by rebasing the whole feature branch. Need frequency request to sync edk2-staging/master to latest edk2/master. This way can also keep branch code go straight with edk2/master. 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe update). That means to use one stable edk2 tag for edk2-staging/HTTPS-TLS branch development. By this way, frequency request to sync edk2-staging/master to latest edk2/master can be avoided but maybe some bugs fixed in edk2/master can't be synced to branch timely. Both of them are not easy since it's probable that each updates in edk2 trunk may cause the conflicts with the HTTPS code (HttpDxe driver and CryptyPkg especially). Effort is almost. Which one do you prefer? Thanks. Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El- > Haj-Mahmoud, Samer > Sent: Thursday, May 19, 2016 6:10 AM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Subject: [edk2] edk2-staging/HTTPS-TLS > > Jiaxin, > > The HTTPs-TLS branch is behind EDK2 master, and they are quite a few > conflicts to try to keep up with both. Can you please sync the branch from > EDK2 master? > > Thanks, > --Samer > > ___ > 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] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc
Gary, good catching! Wrap->TcpWrap.IsRxDone is invalid if it's freed in
HttpTcpReceiveNotifyDpc. But, if you remove it directly, Wrap will not be freed
for each TcpReceive in your patch. Actually, we should free it before return
HttpResponseWorker.
//
// We still need receive more data when there is no cache data and
MsgParser is not NULL;
//
Status = HttpTcpReceiveBody (Wrap, HttpMsg, HttpInstance->TimeoutEvent);
gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
if (EFI_ERROR (Status)) {
goto Error;
}
FreePool (Wrap);< Free it here.
return Status;
Thanks.
Jiaxin
> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Thursday, May 19, 2016 11:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Fu, Siyuan ; El-
> Haj-Mahmoud, Samer ; Laszlo Ersek
> ; Hegde, Nagaraj P
> Subject: [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in
> HttpTcpReceiveNotifyDpc
>
> The HTTP Token Wrap is created in EfiHttpResponse() and then passed to the
> deferred Receive event callback, HttpTcpReceiveNotifyDpc.
> HttpTcpReceiveHeader and HttpTcpReceiveBody use a Tcp polling loop to
> monitor the socket status and trigger the Receive event when a new packet
> arrives. The Receive event brings up HttpTcpReceiveNotifyDpc to process the
> HTTP message and the function will set Wrap->TcpWrap.IsRxDone to TRUE to
> break the Tcp polling loop.
>
> However, HttpTcpReceiveNotifyDpc mistakenly freed Wrap, so the Tcp
> polling loop was actually checking a dead variable, and this led the system
> into an unstable status.
>
> Given the fact that the HTTP Token Wrap will be freed in EfiHttpResponse or
> HttpResponseWorker, this commit removes every "FreePool (Wrap)" in
> HttpTcpReceiveNotifyDpc.
>
> Cc: "Wu, Jiaxin"
> Cc: "Siyuan Fu"
> Cc: "El-Haj-Mahmoud, Samer"
> Cc: "Laszlo Ersek"
> Cc: "Hegde, Nagaraj P"
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gary Lin
> ---
> NetworkPkg/HttpDxe/HttpProto.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c index f3992ed..afa7fe4 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -152,7 +152,6 @@ HttpTcpReceiveNotifyDpc (
> if (EFI_ERROR (Wrap->TcpWrap.Rx6Token.CompletionToken.Status)) {
>Wrap->HttpToken->Status = Wrap-
> >TcpWrap.Rx6Token.CompletionToken.Status;
>gBS->SignalEvent (Wrap->HttpToken->Event);
> - FreePool (Wrap);
>return ;
> }
>
> @@ -162,7 +161,6 @@ HttpTcpReceiveNotifyDpc (
> if (EFI_ERROR (Wrap->TcpWrap.Rx4Token.CompletionToken.Status)) {
>Wrap->HttpToken->Status = Wrap-
> >TcpWrap.Rx4Token.CompletionToken.Status;
>gBS->SignalEvent (Wrap->HttpToken->Event);
> - FreePool (Wrap);
>return ;
> }
>}
> @@ -234,8 +232,6 @@ HttpTcpReceiveNotifyDpc (
>// Check pending RxTokens and receive the HTTP message.
>//
>NetMapIterate (&Wrap->HttpInstance->RxTokens, HttpTcpReceive, NULL);
> -
> - FreePool (Wrap);
> }
>
> /**
> --
> 2.8.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status check of SockProcessRcvToken
Reviewed-By: Wu Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gary Lin
> Sent: Thursday, May 19, 2016 11:49 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin
> Subject: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status check
> of SockProcessRcvToken
>
> SockProcessRcvToken only returns the number of the received bytes, not an
> EFI Status.
>
> Cc: "Siyuan Fu"
> Cc: "Jiaxin Wu"
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gary Lin
> ---
> NetworkPkg/TcpDxe/SockInterface.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/NetworkPkg/TcpDxe/SockInterface.c
> b/NetworkPkg/TcpDxe/SockInterface.c
> index 4abda74..1f3524b 100644
> --- a/NetworkPkg/TcpDxe/SockInterface.c
> +++ b/NetworkPkg/TcpDxe/SockInterface.c
> @@ -724,11 +724,7 @@ SockRcv (
>}
>
>if (RcvdBytes != 0) {
> -Status = SockProcessRcvToken (Sock, RcvToken);
> -
> -if (EFI_ERROR (Status)) {
> - goto Exit;
> -}
> +SockProcessRcvToken (Sock, RcvToken);
>
> Status = Sock->ProtoHandler (Sock, SOCK_CONSUMED, NULL);
>} else {
> --
> 2.8.2
>
> ___
> 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] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status check of SockProcessRcvToken
MdeModulePkg\Universal\Network\Tcp4Dxe has the same issue, I will provide
another patch to fix it also.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wu, Jiaxin
> Sent: Friday, May 20, 2016 8:31 AM
> To: Gary Lin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan
> Subject: Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status
> check of SockProcessRcvToken
>
> Reviewed-By: Wu Jiaxin
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Gary Lin
> > Sent: Thursday, May 19, 2016 11:49 AM
> > To: edk2-devel@lists.01.org
> > Cc: Fu, Siyuan ; Wu, Jiaxin
> > Subject: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status
> check
> > of SockProcessRcvToken
> >
> > SockProcessRcvToken only returns the number of the received bytes, not
> > an EFI Status.
> >
> > Cc: "Siyuan Fu"
> > Cc: "Jiaxin Wu"
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Gary Lin
> > ---
> > NetworkPkg/TcpDxe/SockInterface.c | 6 +-
> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/NetworkPkg/TcpDxe/SockInterface.c
> > b/NetworkPkg/TcpDxe/SockInterface.c
> > index 4abda74..1f3524b 100644
> > --- a/NetworkPkg/TcpDxe/SockInterface.c
> > +++ b/NetworkPkg/TcpDxe/SockInterface.c
> > @@ -724,11 +724,7 @@ SockRcv (
> >}
> >
> >if (RcvdBytes != 0) {
> > -Status = SockProcessRcvToken (Sock, RcvToken);
> > -
> > -if (EFI_ERROR (Status)) {
> > - goto Exit;
> > -}
> > +SockProcessRcvToken (Sock, RcvToken);
> >
> > Status = Sock->ProtoHandler (Sock, SOCK_CONSUMED, NULL);
> >} else {
> > --
> > 2.8.2
> >
> > ___
> > 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] edk2-staging/HTTPS-TLS
Thanks all of your points. So, option 1 is preferred (Keep the liner commit history). And I agree to regular sync edk2-staging/master to latest edk2/master automatically, but not for each feature branch's rebase. Jordan, If no objection, can you help to set up this regular sync between edk2-staging/master and edk2/master? If so, you can avoid the frequency request. Samer, I will resolve the conflicts once the regular sync finished. Thanks. Jiaxin > -Original Message- > From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hpe.com] > Sent: Thursday, May 19, 2016 9:27 PM > To: Laszlo Ersek ; Gao, Liming ; > Wu, Jiaxin ; Li, Ruth ; Ye, Ting > ; Long, Qin ; edk2- > de...@lists.01.org ; Justen, Jordan L > ; Kinney, Michael D > ; Leif Lindholm (Linaro address) > > Subject: RE: [edk2] edk2-staging/HTTPS-TLS > > I do have some experience maintaining my branches (in other projects) that > eventually get submitted as pull requests to a master. And I always find it > easier to keep my branch in sync by doing frequent merge form master. I > agree that it probably makes more sense to do this a couple of times a week > (or so) manually, and resolve any merge conflicts, than try to automate it. > > At this point, I am working on enabling the HTTPS/TLS feature, but I need to > do so in a code base that is up-to-date with EDK2 master. So the main issue I > have is merging from (the now falling behind) HTTPS/TLS branch into my > code base (which is tracking EDK2). As Laszlo said, it is already getting mad > because of all of the HTTP fixes in EDK2. > > Thanks, > --Samer > > > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, May 19, 2016 5:51 AM > To: Gao, Liming ; Wu, Jiaxin ; > El-Haj-Mahmoud, Samer ; Li, Ruth > ; Ye, Ting ; Long, Qin > ; edk2-devel@lists.01.org ; > Justen, Jordan L ; Kinney, Michael D > ; Leif Lindholm (Linaro address) > > Subject: Re: [edk2] edk2-staging/HTTPS-TLS > > On 05/19/16 11:53, Gao, Liming wrote: > > Ersek: > > I remember we discuss Rebase or Merge before. The conclusion is to > > keep the liner history in edk2 project. So, I think rebase is better. > > Okay. > > > If we choose option 1, I suggest to setup mirror task in server and > > auto run regular sync. If the confliction happens, it sends the mail > > to edk dev list and let owner follow up. > > Hmm... I'm not sure about an automated rebase. I always have a number of > downstream branches (in my private repo) that I rebase almost every day to > new master. > > However, occasionally I'm so deep in work that I don't want to rebase for a > week, for example. An automated rebase would be very annoying in such > situations, when I'm in the middle of shuffling around my patches. > > I think it's the owner's responsibility after all. If they are fine with an > automated rebase, so be it; but the automatism should be possible to disable. > > Thanks > Laszlo > > > Thanks > > Liming > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > >> Of Laszlo Ersek > >> Sent: Thursday, May 19, 2016 4:31 PM > >> To: Wu, Jiaxin ; El-Haj-Mahmoud, Samer > >> ; Li, Ruth ; Ye, > >> Ting ; Long, Qin ; edk2- > >> de...@lists.01.org ; Justen, Jordan L > >> ; Kinney, Michael D > >> ; Leif Lindholm (Linaro address) > >> > >> Subject: Re: [edk2] edk2-staging/HTTPS-TLS > >> > >> On 05/19/16 05:35, Wu, Jiaxin wrote: > >>> Hi all, > >>> There are two ways to sync HTTPS-TLS branch with EDK2 master: > >>> > >>> 1. Sync all changes in EDK2 master to branch by rebasing the whole > >>> feature branch. Need frequency request to sync edk2-staging/master > >>> to latest edk2/master. This way can also keep branch code go > >>> straight with edk2/master. > >>> > >>> 2. Only sync HTTPS/TLS related patches to branch (e.g. HttpDxe > >>> update). That means to use one stable edk2 tag for > >>> edk2-staging/HTTPS-TLS branch development. By this way, frequency > >>> request to sync edk2-staging/master to latest edk2/master can be > >>> avoided but maybe some bugs fixed in edk2/master can't be synced to > >>> branch timely. > >>> > >>> Both of them are not easy since it's probable that each updates in > >>> edk2 trunk may cause the conflicts with the HTTPS code (HttpDxe > >>> driver and CryptyPkg especially). > >>> > >>> Effort is almost
Re: [edk2] [PATCH v2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc
Reviewed-By: Wu Jiaxin
> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Friday, May 20, 2016 11:18 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Fu, Siyuan ; El-
> Haj-Mahmoud, Samer ; Laszlo Ersek
> ; Hegde, Nagaraj P
> Subject: [PATCH v2] NetworkPkg/HttpDxe: Don't free Wrap in
> HttpTcpReceiveNotifyDpc
>
> The HTTP Token Wrap is created in EfiHttpResponse() and then passed to the
> deferred Receive event callback, HttpTcpReceiveNotifyDpc.
> HttpTcpReceiveHeader and HttpTcpReceiveBody use a Tcp polling loop to
> monitor the socket status and trigger the Receive event when a new packet
> arrives. The Receive event brings up HttpTcpReceiveNotifyDpc to process the
> HTTP message and the function will set Wrap->TcpWrap.IsRxDone to TRUE to
> break the Tcp polling loop.
>
> However, HttpTcpReceiveNotifyDpc mistakenly freed Wrap, so the Tcp
> polling loop was actually checking a dead variable, and this led the system
> into an unstable status.
>
> Given the fact that the HTTP Token Wrap will be freed in EfiHttpResponse or
> HttpResponseWorker, this commit removes every "FreePool (Wrap)" in
> HttpTcpReceiveNotifyDpc.
>
> v2:
> * Free Wrap after HttpTcpReceiveBody returns normally.
>
> Cc: "Wu, Jiaxin"
> Cc: "Siyuan Fu"
> Cc: "El-Haj-Mahmoud, Samer"
> Cc: "Laszlo Ersek"
> Cc: "Hegde, Nagaraj P"
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gary Lin
> ---
> NetworkPkg/HttpDxe/HttpImpl.c | 1 +
> NetworkPkg/HttpDxe/HttpProto.c | 4
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index dd10f82..f4ae28a 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -1237,6 +1237,7 @@ HttpResponseWorker (
> goto Error;
>}
>
> + FreePool (Wrap);
>return Status;
>
> Exit:
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c index f3992ed..afa7fe4 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -152,7 +152,6 @@ HttpTcpReceiveNotifyDpc (
> if (EFI_ERROR (Wrap->TcpWrap.Rx6Token.CompletionToken.Status)) {
>Wrap->HttpToken->Status = Wrap-
> >TcpWrap.Rx6Token.CompletionToken.Status;
>gBS->SignalEvent (Wrap->HttpToken->Event);
> - FreePool (Wrap);
>return ;
> }
>
> @@ -162,7 +161,6 @@ HttpTcpReceiveNotifyDpc (
> if (EFI_ERROR (Wrap->TcpWrap.Rx4Token.CompletionToken.Status)) {
>Wrap->HttpToken->Status = Wrap-
> >TcpWrap.Rx4Token.CompletionToken.Status;
>gBS->SignalEvent (Wrap->HttpToken->Event);
> - FreePool (Wrap);
>return ;
> }
>}
> @@ -234,8 +232,6 @@ HttpTcpReceiveNotifyDpc (
>// Check pending RxTokens and receive the HTTP message.
>//
>NetMapIterate (&Wrap->HttpInstance->RxTokens, HttpTcpReceive, NULL);
> -
> - FreePool (Wrap);
> }
>
> /**
> --
> 2.8.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] HTTP Boot crashed when downloading remote image
Gary, Timeout case could happened by any abruptly interrupted (e.g. network disconnection, cable plug/unplug...). Some exception behavior may happened while Timeout triggered. The rootcause as I descripted below: If TCP CompletionToken is not signaled, it should not be closed directly by calling CloseEvent after timeout happened (Still in the TCP RcvTokenList). If not, any exception behavior may be triggered. We should cancel it by calling Tcp->Cancel(), then close it. but unfortunately, Tcp->Cancel() is unsupported currently. However, we can flush the tokens in TCP token list(what we want to do) by closing the existing TCP connection(Actually we should!). It's the safe operation. Please help to verify the corresponding patch in edk2 mailing list. Title as below: [edk2] [Patch] NetworkPkg: Need update Http token status while timeout happened Thanks. Jiaxin > -Original Message- > From: Gary Lin [mailto:g...@suse.com] > Sent: Thursday, May 19, 2016 12:11 PM > To: Wu, Jiaxin > Cc: El-Haj-Mahmoud, Samer ; Laszlo > Ersek ; Hegde, Nagaraj P p.he...@hpe.com>; edk2-devel@lists.01.org > Subject: Re: [edk2] HTTP Boot crashed when downloading remote image > > On Thu, May 19, 2016 at 02:11:34AM +, Wu, Jiaxin wrote: > > Thanks Gary. We also found that if TCP CompletionToken is not signaled, it > should not be closed directly by calling CloseEvent after timeout > happened(Still in the TCP RcvTokenList). If not, any exception behavior may > be triggered while more packets continue received but only timeout > happened (do you root cause? I'm glad to know.). We should cancel it by > calling Tcp4->Cancel(), then close it. but unfortunately, Tcp4->Cancel() is > unsupported currently. > > > Hi Jiaxin, > > The case I encountered is that HttpTcpReceiveNotifyDpc freed Wrap > mistakenly and caused the instability of the system (just sent the patch). > Actually the timeout shouldn't show in my case since I used a VM to connect > to the host to download a small EFI file. > > Anyway, the problem you mentioned looks valid to me and maybe I should > try to make a timeout test. > > Thanks, > > Gary Lin > > > Thanks. > > Jiaxin > > > > > -Original Message- > > > From: Gary Lin [mailto:g...@suse.com] > > > Sent: Thursday, May 19, 2016 10:06 AM > > > To: El-Haj-Mahmoud, Samer ; Laszlo > > > Ersek > > > Cc: edk2-devel@lists.01.org; Wu, Jiaxin > > > Subject: Re: [edk2] HTTP Boot crashed when downloading remote image > > > > > > On Wed, May 18, 2016 at 01:54:24PM +, El-Haj-Mahmoud, Samer > wrote: > > > > Gary, > > > > > > > > The EDK2 list blocked the wireshark attachment. Can you put it on > > > > a share > > > and send a link please? We are trying to look at this internally as well. > > > Hi Samer and Laszlo, > > > > > > I've found the root cause. I'll send a patch later and Cc you guys. > > > > > > Thanks, > > > > > > Gary Lin > > > > > > > > > > > Thanks, > > > > --Samer > > > > > > > > -Original Message- > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On > > > > Behalf Of Gary Lin > > > > Sent: Tuesday, May 17, 2016 11:29 PM > > > > To: edk2-devel@lists.01.org > > > > Cc: Jiaxin Wu > > > > Subject: Re: [edk2] HTTP Boot crashed when downloading remote > > > > image > > > > > > > > On Thu, May 12, 2016 at 06:26:36PM +0800, Gary Lin wrote: > > > > > Hi, > > > > > > > > > > I was testing HTTP Boot with the latest OMVF and found that it > > > > > crashed when downloading the remote image from the http server. > > > > > Here is my bisect result: > > > > > > > > > > commit b347a22aecbfac9aac47831fee9a30aa810d6d0b > > > > > NetworkPkg: Avoid the indefinite wait case in HttpDxe > > > > > > > > > > Actually, it sometimes worked but was broken for the most of time. > > > > > Reverting this patch makes HTTP Boot always work. > > > > > > > > > > It seems the IP4 driver tried to remove a mnp event, but the > > > > > event list was empty so the assert was triggered. > > > > > > > > > Some findings: > > > > > > > > 1. OVMF could crash without b347a22ae in a slight different way. > > > >Several "TcpInput: Discard a packet" showed without the assert. > > > &g
Re: [edk2] [Patch] NetworkPkg: update code for NULL pointer check.
Reviewed-By: Wu Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Monday, May 23, 2016 5:49 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: [Patch] NetworkPkg: update code for NULL pointer check.
>
> This patch updates the HTTP driver to initialize the local variable for NULL
> and
> check the NULL pointer before dereference it.
>
> Cc: Ye Ting
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan
> ---
> NetworkPkg/HttpDxe/HttpImpl.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index f4ae28a..7ee6613 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -253,6 +253,7 @@ EfiHttpRequest (
>// Initializations
>//
>Url = NULL;
> + UrlParser = NULL;
>HostName = NULL;
>RequestMsg = NULL;
>HostNameStr = NULL;
> @@ -1063,7 +1064,7 @@ HttpResponseWorker (
> if (SizeofHeaders != 0) {
>HeaderTmp = AllocateZeroPool (SizeofHeaders);
>if (HeaderTmp == NULL) {
> -goto Error;
> +goto Error2;
>}
>
>CopyMem (HeaderTmp, Tmp, SizeofHeaders); @@ -1075,7 +1076,7 @@
> HttpResponseWorker (
>//
>if (mHttpUtilities == NULL) {
> Status = EFI_NOT_READY;
> -goto Error;
> +goto Error2;
>}
>
>//
> @@ -1089,7 +1090,7 @@ HttpResponseWorker (
> &HttpMsg->HeaderCount
> );
>if (EFI_ERROR (Status)) {
> -goto Error;
> +goto Error2;
>}
>
>FreePool (HttpHeaders);
> @@ -1214,7 +1215,7 @@ HttpResponseWorker (
> &HttpInstance->TimeoutEvent
> );
> if (EFI_ERROR (Status)) {
> - goto Error;
> + goto Error2;
> }
>}
>
> @@ -1223,7 +1224,7 @@ HttpResponseWorker (
>//
>Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
>if (EFI_ERROR (Status)) {
> -goto Error;
> +goto Error2;
>}
>
>//
> @@ -1234,7 +1235,7 @@ HttpResponseWorker (
>gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
>
>if (EFI_ERROR (Status)) {
> -goto Error;
> +goto Error2;
>}
>
>FreePool (Wrap);
> @@ -1258,7 +1259,9 @@ Exit:
>return Status;
>
> Error2:
> - NetMapInsertHead (&HttpInstance->TxTokens, ValueInItem->HttpToken,
> ValueInItem);
> + if (ValueInItem != NULL) {
> +NetMapInsertHead (&HttpInstance->TxTokens, ValueInItem->HttpToken,
> + ValueInItem); }
>
> Error:
>HttpTcpTokenCleanup (Wrap);
> --
> 2.7.4.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg: Need update Http token status while timeout happened
Siyuan,
I agree Http->Response() is designed to a unblocking interface. Actually,
current implementation is blocking one. So, handling EFI_TIMEOUT status in the
token (HttpBootDxe driver) or return directly, both of them are fine to me .
But Tcp->Cancel() still should be necessary calling if we handle the case in
HttpBootDxe driver.
Thanks.
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, May 24, 2016 9:17 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Gary Lin ; Samer El-Haj-
> Mahmoud ; Hegde Nagaraj P
> Subject: RE: [Patch] NetworkPkg: Need update Http token status while
> timeout happened
>
> Hi, Jiaxin
>
> The Http->Response() is a unblocking interface, that the function return
> status should be SUCCESS once the token has been queued to the driver.
> Then if there is an error later, the Status in the token should be updated and
> Event will be signaled.
> So I think the original code in HTTP driver does make sense, but the HTTP
> boot driver function has bug that, when download the message body, it
> should also check the Status in the token, not only the function.
>
> Best Regards
> Siyuan
>
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Friday, May 20, 2016 3:24 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ;
> > Gary Lin ; Samer El-Haj-Mahmoud ;
> Hegde
> > Nagaraj P
> > Subject: [Patch] NetworkPkg: Need update Http token status while
> > timeout happened
> >
> > Http token status should be updated to EFI_TIMEOUT while timeout
> > happened by any abruptly interrupted (e.g. network disconnection,
> > cable plug/unplug...). Otherwise, HttpBootDxe driver will continue
> > treat it as no error happened, and its ReceivedSize will be updated to
> > ContentLength directly. Moreover, If download image type is RAM Disk,
> > the corresponding info will be registered to system.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Gary Lin
> > Cc: Samer El-Haj-Mahmoud
> > Cc: Hegde Nagaraj P
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiaxin Wu
> > ---
> > NetworkPkg/HttpDxe/HttpImpl.c | 3 +++
> > NetworkPkg/HttpDxe/HttpProto.c | 16 +++-
> > 2 files changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> > b/NetworkPkg/HttpDxe/HttpImpl.c index f4ae28a..05a96e9 100644
> > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > @@ -1259,10 +1259,13 @@ Exit:
> >
> > Error2:
> >NetMapInsertHead (&HttpInstance->TxTokens, ValueInItem->HttpToken,
> > ValueInItem);
> >
> > Error:
> > +
> > + HttpCloseConnection (HttpInstance);
> > +
> >HttpTcpTokenCleanup (Wrap);
> >
> >if (HttpHeaders != NULL) {
> > FreePool (HttpHeaders);
> >}
> > diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> > b/NetworkPkg/HttpDxe/HttpProto.c index afa7fe4..c3608c0 100644
> > --- a/NetworkPkg/HttpDxe/HttpProto.c
> > +++ b/NetworkPkg/HttpDxe/HttpProto.c
> > @@ -1,9 +1,9 @@
> > /** @file
> >Miscellaneous routines for HttpDxe driver.
> >
> > -Copyright (c) 2015, Intel Corporation. All rights reserved.
> > +Copyright (c) 2015 - 2016, 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
> > @@ -1605,10 +1605,11 @@ HttpTcpReceiveHeader (
> >while (!HttpInstance->IsRxDone && ((Timeout == NULL) ||
> > EFI_ERROR (gBS->CheckEvent (Timeout {
> > Tcp4->Poll (Tcp4);
> >}
> >
> >if (!HttpInstance->IsRxDone) {
> > +Tcp4->Cancel (Tcp4, &Rx4Token->CompletionToken);
> > gBS->CloseEvent (Rx4Token->CompletionToken.Event);
> > Rx4Token->CompletionToken.Status = EFI_TIMEOUT;
> >}
> >
> >Status = Rx4Token->CompletionToken.Status; @@ -1671,10 +1672,11
> > @@ HttpTcpReceiveHeader (
> >while (!HttpInstance->IsRxDone && ((Timeout == NULL) ||
> > EFI_ERROR (gBS->CheckEvent (Timeout {
> > Tcp6->Poll (Tcp6);
> >}
> >
> >if (!HttpInstance->IsRxDone) {
> > +
Re: [edk2] edk2-staging/HTTPS-TLS
Finished sync the branch from EDK2 master. Thanks. Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El- > Haj-Mahmoud, Samer > Sent: Thursday, May 19, 2016 6:10 AM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Subject: [edk2] edk2-staging/HTTPS-TLS > > Jiaxin, > > The HTTPs-TLS branch is behind EDK2 master, and they are quite a few > conflicts to try to keep up with both. Can you please sync the branch from > EDK2 master? > > Thanks, > --Samer > > ___ > 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] [Patch 0/2] Stop-the-timer-before-clean-IP-service
Serials Reviewed-by: Wu Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu > Siyuan > Sent: Thursday, May 26, 2016 9:04 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch 0/2] Stop-the-timer-before-clean-IP-service > > Fu Siyuan (2): > MdeModulePkg: Stop the timer before clean IP service. > NetworkPkg: Stop the timer before clean IP service. > > MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 18 ++--- > NetworkPkg/Ip6Dxe/Ip6Driver.c | 31 > --- > 2 files changed, 25 insertions(+), 24 deletions(-) > > -- > 2.7.4.windows.1 > > ___ > 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] [Patch] MdeModulePkg: Fix SNP.Initialize() spec conformance issue
Thanks Ting, version2 patch will be sent out later. After that, I will
highlight it with your comments again.
Thanks.
Jiaxin
> -Original Message-
> From: Ye, Ting
> Sent: Thursday, May 26, 2016 2:52 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan
> Subject: RE: [Patch] MdeModulePkg: Fix SNP.Initialize() spec conformance
> issue
>
> Jiaxin,
>
> It looks to me the three places of below code can be merged together.
> Please double check.
>
> +Snp->Mode.State = EfiSimpleNetworkInitialized;
> +Status = EFI_SUCCESS;
>
> Also, I would like to highlight that the patch might bring interoperability
> issues to the NIC cards which do not comply with the UNDI definitions in UEFI
> spec. We validated some Intel NICs and they worked probably with this patch.
> If anyone in the mailing list meet the interoperability issue please raise to
> us.
>
> Thanks,
> Ye Ting
>
> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, May 26, 2016 9:10 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan
> Subject: [Patch] MdeModulePkg: Fix SNP.Initialize() spec conformance issue
>
> Current SNP UNDI Initialize command does not follow the UEFI Spec to
> update the SNP MediaPresent field. The result for the Initialize command
> execution check should be:
> StatFlags: (1) Monitor the upper two bits (14 & 15) in the field to know
> whether the command has been executed by the UNDI (Not started,
> Queued, Error, Complete). (2) Check the other field to see if there is an
> active connection to this network device (used to update MediaPresent).
> StatCode: After command execution completes, either successfully or not,
> this field contains the result of the command execution (success or failure).
> This patch is used to fix it.
>
> NOTE: If any UNDI driver does not follow the UEFI Spec for the media status
> update, it may meet failure with this more conditions check (StatFlags).
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> MdeModulePkg/Universal/Network/SnpDxe/Initialize.c | 37
> ++
> 1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> index 2151375..0c292a5 100644
> --- a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> +++ b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> @@ -1,9 +1,9 @@
> /** @file
> Implementation of initializing a network adapter.
>
> -Copyright (c) 2004 - 2008, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 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
>
> @@ -35,10 +35,12 @@ PxeInit (
> {
>PXE_CPB_INITIALIZE *Cpb;
>VOID*Addr;
>EFI_STATUS Status;
>
> + Status = EFI_SUCCESS;
> +
>Cpb = Snp->Cpb;
>if (Snp->TxRxBufferSize != 0) {
> Status = Snp->PciIo->AllocateBuffer (
> Snp->PciIo,
> AllocateAnyPages, @@ -97,14 +99,38 @@ PxeInit (
>
>DEBUG ((EFI_D_NET, "\nSnp->undi.initialize() "));
>
>(*Snp->IssueUndi32Command) ((UINT64)(UINTN) &Snp->Cdb);
>
> - if (Snp->Cdb.StatCode == PXE_STATCODE_SUCCESS) {
> -Snp->Mode.State = EfiSimpleNetworkInitialized;
> -
> -Status = EFI_SUCCESS;
> + //
> + // There are two fields need to be checked here:
> + // First is the upper two bits (14 & 15) in the CDB.StatFlags field.
> + Until these bits change to report //
> PXE_STATFLAGS_COMMAND_COMPLETE or
> PXE_STATFLAGS_COMMAND_FAILED, the command has not been executed
> by the UNDI.
> + // Second is the CDB.StatCode field. After command execution
> + completes, either successfully or not, // the CDB.StatCode field contains
> the result of the command execution.
> + //
> + if Snp->Cdb.StatFlags) & PXE_STATFLAGS_STATUS_MASK) ==
> PXE_STATFLAGS_COMMAND_COMPLETE) &&
> + (Snp->Cdb.StatCode == PXE_STATCODE_SUCCESS)) {
> +//
> +// If cable detect feature is enabled in CDB.OpFlags, check the
> CDB.StatFlags to see if there is an
> +// active connection to this network device. If the no media StatFlag is
> set,
> the UNDI and network
> +// device are still initialized.
Re: [edk2] [PATCH v2] MdeModulePkg: Fix SNP.Initialize() spec conformance issue
Hi All,
This patch may bring interoperability issues to the NIC cards which do not
comply with the UNDI definitions in UEFI spec (Appendix E). We have validated
some Intel NICs and they worked probably with this patch. If anyone in the
mailing list meet the interoperability issue with this patch. Please raise to
us.
Thanks and Best Regards!
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, May 31, 2016 10:34 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan
> Subject: [edk2] [PATCH v2] MdeModulePkg: Fix SNP.Initialize() spec
> conformance issue
>
> v2:
> *Refine the coding style according edk2 community's feedback.
>
> Current SNP UNDI Initialize command does not follow the UEFI Spec to
> update the SNP MediaPresent field. The result for the Initialize command
> execution check should be:
> StatFlags: (1) Monitor the upper two bits (14 & 15) in the field to know
> whether the command has been executed by the UNDI (Not started,
> Queued, Error, Complete). (2) Check the other field to see if there is an
> active connection to this network device (used to update MediaPresent).
> StatCode: After command execution completes, either successfully or not,
> this field contains the result of the command execution (success or failure).
> This patch is used to fix it.
>
> NOTE: If any UNDI driver does not follow the UEFI Spec for the media status
> update, it may meet failure with this more conditions check (StatFlags).
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> MdeModulePkg/Universal/Network/SnpDxe/Initialize.c | 33
> ++
> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> index 2151375..63bdf92 100644
> --- a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> +++ b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
> @@ -1,9 +1,9 @@
> /** @file
> Implementation of initializing a network adapter.
>
> -Copyright (c) 2004 - 2008, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 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
>
> @@ -35,10 +35,12 @@ PxeInit (
> {
>PXE_CPB_INITIALIZE *Cpb;
>VOID*Addr;
>EFI_STATUS Status;
>
> + Status = EFI_SUCCESS;
> +
>Cpb = Snp->Cpb;
>if (Snp->TxRxBufferSize != 0) {
> Status = Snp->PciIo->AllocateBuffer (
> Snp->PciIo,
> AllocateAnyPages, @@ -97,14 +99,34 @@ PxeInit (
>
>DEBUG ((EFI_D_NET, "\nSnp->undi.initialize() "));
>
>(*Snp->IssueUndi32Command) ((UINT64)(UINTN) &Snp->Cdb);
>
> - if (Snp->Cdb.StatCode == PXE_STATCODE_SUCCESS) {
> -Snp->Mode.State = EfiSimpleNetworkInitialized;
> -
> -Status = EFI_SUCCESS;
> + //
> + // There are two fields need to be checked here:
> + // First is the upper two bits (14 & 15) in the CDB.StatFlags field.
> + Until these bits change to report //
> PXE_STATFLAGS_COMMAND_COMPLETE or
> PXE_STATFLAGS_COMMAND_FAILED, the command has not been executed
> by the UNDI.
> + // Second is the CDB.StatCode field. After command execution
> + completes, either successfully or not, // the CDB.StatCode field contains
> the result of the command execution.
> + //
> + if Snp->Cdb.StatFlags) & PXE_STATFLAGS_STATUS_MASK) ==
> PXE_STATFLAGS_COMMAND_COMPLETE) &&
> + (Snp->Cdb.StatCode == PXE_STATCODE_SUCCESS)) {
> +//
> +// If cable detect feature is enabled in CDB.OpFlags, check the
> CDB.StatFlags to see if there is an
> +// active connection to this network device. If the no media StatFlag is
> set,
> the UNDI and network
> +// device are still initialized.
> +//
> +if (CableDetectFlag == PXE_OPFLAGS_INITIALIZE_DETECT_CABLE) {
> + if(((Snp->Cdb.StatFlags) & PXE_STATFLAGS_INITIALIZED_NO_MEDIA) !=
> PXE_STATFLAGS_INITIALIZED_NO_MEDIA) {
> +Snp->Mode.MediaPresent = TRUE;
> + } else {
> +Snp->Mode.MediaPresent = FALSE;
> + }
> +}
> +
> +Snp->Mode.State = EfiSimpleNetworkInitialized;
> +Status= EFI_SUCCESS;
>} else {
> DEBUG (
>(EFI_D_WARN,
>"\nSnp->undi.initialize() %xh:%xh\n",
>Snp->Cdb.StatFlags,
> @@ -232,11 +254,10 @@ SnpUndi32Initialize (
>//
>// If UNDI support cable detect for INITIALIZE command, try it first.
>//
>if (Snp->CableDetectSupported) {
> if (PxeInit (Snp, PXE_OPFLAGS_INITIALIZE_DETECT_CABLE) ==
> EFI_SUCCESS) {
> - Snp->Mode.MediaPrese
Re: [edk2] [Patch 0/3] NetworkPkg: Support TCP Cancel function and move timeout handling to HttpBootDxe
Hi Nagaraj and Gary, Please help to review and verify the series patches. Thanks and Best regards! Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jiaxin Wu > Sent: Tuesday, May 31, 2016 10:17 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Zhang, Lubo ; Fu, > Siyuan ; Gary Lin > Subject: [edk2] [Patch 0/3] NetworkPkg: Support TCP Cancel function and > move timeout handling to HttpBootDxe > > Cc: Ye Ting > Cc: Fu Siyuan > Cc: Zhang Lubo > Cc: Hegde Nagaraj P > Cc: Gary Lin > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jiaxin Wu > > Jiaxin Wu (3): > NetworkPkg: Support TCP Cancel function > NetworkPkg: HttpDxe response/cancel issue fix > NetworkPkg: Handling timeout case in httpboot driver > > NetworkPkg/HttpBootDxe/HttpBootClient.c | 10 +- > NetworkPkg/HttpBootDxe/HttpBootClient.h |1 + > NetworkPkg/HttpBootDxe/HttpBootSupport.c | 2346 ++- > NetworkPkg/HttpBootDxe/HttpBootSupport.h |2 + > NetworkPkg/HttpDxe/HttpImpl.c| 2918 --- > NetworkPkg/HttpDxe/HttpProto.c | 3770 +++ > --- > NetworkPkg/HttpDxe/HttpProto.h |4 +- > NetworkPkg/TcpDxe/SockImpl.c | 2525 ++-- > NetworkPkg/TcpDxe/SockImpl.h | 223 +- > NetworkPkg/TcpDxe/SockInterface.c| 2080 + > NetworkPkg/TcpDxe/Socket.h | 1866 +++ > NetworkPkg/TcpDxe/TcpMain.c | 2183 - > NetworkPkg/TcpDxe/TcpMain.h | 1549 ++-- > 13 files changed, 9872 insertions(+), 9605 deletions(-) > > -- > 1.9.5.msysgit.1 > > ___ > 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] [Patch 2/2] NetworkPkg: Stop the timer before clean IP service.
Hi Bruce, Thanks for your catching, I will check my git email setting. Best Regards! Jiaxin > -Original Message- > From: Bruce Cran [mailto:br...@cran.org.uk] > Sent: Thursday, June 2, 2016 8:33 AM > To: Fu, Siyuan ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Wu, Jiaxin > Subject: Re: [edk2] [Patch 2/2] NetworkPkg: Stop the timer before clean IP > service. > > On 5/25/16 7:04 PM, Fu Siyuan wrote: > > In Ip6CleanService()it first cleaned some resources, then stop the timer . > > While before the timer stopped it may try to access some already freed > > data, which may generate an exception. > > This patch updates the driver to stop the timer event before starting > > to clean up the service data. > > > > Cc: Wu Jiaxin > > Cc: Ye Ting > > Cc: Subramanian Sriram > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Fu Siyuan > > I'm seeing strange "authored by" data in your changesets. For example, in: > > NetworkPkg: Stop the timer before clean IP service. > 5c944a654a68 > > Authored by Fu, Siyuan Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=sfu5> on Wed, > May 25, 7:04 PM. > > Could you check your git email setting please? > > -- > Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 2/2] NetworkPkg: Stop the timer before clean IP service.
> -Original Message- > From: Bruce Cran [mailto:br...@cran.org.uk] > Sent: Thursday, June 2, 2016 12:54 PM > To: Wu, Jiaxin ; Fu, Siyuan ; > edk2-devel@lists.01.org > Cc: Ye, Ting ; Ni, Ruiyu ; Wu, Hao A > > Subject: Re: [edk2] [Patch 2/2] NetworkPkg: Stop the timer before clean IP > service. > > On 6/1/16 7:55 PM, Wu, Jiaxin wrote: > > > Thanks for your catching, I will check my git email setting. > > Sorry, it was actually meant for Siyuan. When I extract the patch from Siyuan's patch email, something wrong happened in my extracted patch, which may cause this strange "authored by" data. So, I think it's not Siyuan's part. Anyway, the issue resolved:). Thanks. Jiaxin > > -- > Bruce ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Remove NULL cipher
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Thomas Palmer
> Sent: Tuesday, June 7, 2016 10:47 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin
> Subject: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib:
> Remove NULL cipher
>
> The term "NULL" refers to NULL-MD5, NULL-SHA and NULL-SHA256 when
> used to set the SSL cipher list. As both MD5 and SHA variants are explicitly
> listed in our code, I surmise enabling all three by setting the cipher list
> to just
> NULL was not the intended behavior.
> This patch will remove NULL as an option for the cipher list and allow NULL-
> SHA256 instead.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Thomas Palmer
> ---
> CryptoPkg/Library/TlsLib/TlsLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c
> b/CryptoPkg/Library/TlsLib/TlsLib.c
> index 9f56b7a..b76dd20 100644
> --- a/CryptoPkg/Library/TlsLib/TlsLib.c
> +++ b/CryptoPkg/Library/TlsLib/TlsLib.c
> @@ -53,7 +53,6 @@ typedef struct {
> // OpenSSL-used Cipher Suite name.
> //
> STATIC CONST TLS_CIPHER_PAIR TlsCipherMappingTable[] = {
> - { 0x, "NULL" }, /// TLS_NULL_WITH_NULL_NULL
>{ 0x0001, "NULL-MD5" }, /// TLS_RSA_WITH_NULL_MD5
>{ 0x0002, "NULL-SHA" }, /// TLS_RSA_WITH_NULL_SHA
>{ 0x0004, "RC4-MD5" }, /// TLS_RSA_WITH_RC4_128_MD5
> @@ -62,6 +61,7 @@ STATIC CONST TLS_CIPHER_PAIR
> TlsCipherMappingTable[] = {
>{ 0x000A, "DES-CBC3-SHA" }, /// TLS_RSA_WITH_3DES_EDE_CBC_SHA
>{ 0x002F, "AES128-SHA" }, /// TLS_RSA_WITH_AES_128_CBC_SHA
>{ 0x0035, "AES256-SHA" }, /// TLS_RSA_WITH_AES_256_CBC_SHA
> + { 0x003B, "NULL-SHA256" }, /// TLS_RSA_WITH_NULL_SHA256
>{ 0x003C, "AES128-SHA256" },/// TLS_RSA_WITH_AES_128_CBC_SHA256
>{ 0x003D, "AES256-SHA256" } /// TLS_RSA_WITH_AES_256_CBC_SHA256
> };
> --
> 1.9.1
>
> ___
> 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] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Handshake failure
Reviewed-By: Wu Jiaxin
I will commit the patch soon. Thanks for the contribution.
Best Regards!
Jiaxin
> -Original Message-
> From: Thomas Palmer [mailto:thomas.pal...@hpe.com]
> Sent: Wednesday, June 8, 2016 2:36 AM
> To: edk2-devel@lists.01.org
> Cc: samer.el-haj-mahm...@hpe.com; Wu, Jiaxin ;
> Thomas Palmer
> Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib:
> Handshake failure
>
> TlsLib should inspect the return from the SSL_do_handshake and return
> EFI_PROTOCOL_ERROR on certain conditions that are not recoverable.
>
> For example, if a client is configured with a certain set of ciphers that the
> TLS
> server does not support, the server will send a fatal alert before the
> handshake finishes. Our TLS protocol only expects an alert to come after the
> handshake, so we would have continued TLS operations.
>
> Please note I am using types int and unsigned long to match the OpenSSL api.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Thomas Palmer
> ---
> CryptoPkg/Library/TlsLib/TlsLib.c | 29 +++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c
> b/CryptoPkg/Library/TlsLib/TlsLib.c
> index b76dd20..8b441a5 100644
> --- a/CryptoPkg/Library/TlsLib/TlsLib.c
> +++ b/CryptoPkg/Library/TlsLib/TlsLib.c
> @@ -616,6 +616,8 @@ TlsDoHandshake (
> {
>TLS_CONNECTION *TlsConn;
>UINTN PendingBufferSize;
> + int ret;
> + unsigned long e;
>
>TlsConn = (TLS_CONNECTION *) Tls;
>PendingBufferSize = 0;
> @@ -638,18 +640,41 @@ TlsDoHandshake (
> PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
> if (PendingBufferSize == 0) {
>SSL_set_connect_state (TlsConn->Ssl);
> - SSL_do_handshake (TlsConn->Ssl);
> + ret = SSL_do_handshake (TlsConn->Ssl);
>PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
> }
>} else {
> PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
> if (PendingBufferSize == 0) {
>BIO_write (TlsConn->InBio, BufferIn, (UINT32) BufferInSize);
> - SSL_do_handshake (TlsConn->Ssl);
> + ret = SSL_do_handshake (TlsConn->Ssl);
>PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
> }
>}
>
> + if (ret < 1) {
> +ret = SSL_get_error (TlsConn->Ssl, ret);
> +if (ret == SSL_ERROR_SSL ||
> +ret == SSL_ERROR_SYSCALL ||
> +ret == SSL_ERROR_ZERO_RETURN) {
> + DEBUG ((DEBUG_ERROR, "%a SSL_HANDSHAKE_ERROR State=0x%x
> SSL_ERROR_%a\n", __FUNCTION__, SSL_state (TlsConn->Ssl),
> +ret == SSL_ERROR_SSL ? "SSL":
> +ret == SSL_ERROR_SYSCALL ? "SYSCALL":
> +"ZERO_RETURN"
> +));
> + DEBUG_CODE_BEGIN ();
> + while (1) {
> +e = ERR_get_error ();
> +if (e == 0) {
> + break;
> +}
> +DEBUG ((DEBUG_ERROR, "%a ERROR 0x%x=L%x:F%x:R%x\n",
> __FUNCTION__, e, ERR_GET_LIB (e), ERR_GET_FUNC (e), ERR_GET_REASON
> (e)));
> + }
> + DEBUG_CODE_END ();
> + return EFI_PROTOCOL_ERROR;
> +}
> + }
> +
>if (PendingBufferSize > *BufferOutSize) {
> *BufferOutSize = PendingBufferSize;
> return EFI_BUFFER_TOO_SMALL;
> --
> 1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg: Fix unspecified address use case in IpsecConfig
Thanks for catching. I will update it before commit. /Jiaxin.
> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, June 15, 2016 4:32 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting ; Zeng,
> Star
> Subject: RE: [Patch] NetworkPkg: Fix unspecified address use case in
> IpsecConfig
>
> Please also update the comments below in SPD_ENTRY_INDEXER structure.
>
> UINTNIndex;// Used only if Name is NULL.
>
> With the comments updated, you can have my Reviewed-by: Star Zeng
>
>
> Thanks,
> Star
> -Original Message-
> From: Wu, Jiaxin
> Sent: Wednesday, June 15, 2016 4:26 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting ; Zeng,
> Star
> Subject: [Patch] NetworkPkg: Fix unspecified address use case in IpsecConfig
>
> This patch is used to fix unspecified address use case in
> ConstructSpdIndexer() function. Indexer->Name for ConstructSpdIndexer is
> unspecified, that will be a problem for UnicodeStrToAsciiStr.
>
> This patch also refine the code by removing ASSERT and user error handling.
>
> Cc: Fu Siyuan
> Cc: Ye Ting
> Cc: Zeng Star
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> NetworkPkg/Application/IpsecConfig/Indexer.c | 26 ---
> --- NetworkPkg/Application/IpsecConfig/Indexer.h | 4 ++--
> NetworkPkg/Application/IpsecConfig/Match.c | 4 ++--
> 3 files changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/NetworkPkg/Application/IpsecConfig/Indexer.c
> b/NetworkPkg/Application/IpsecConfig/Indexer.c
> index 83ceda4..353b22e 100644
> --- a/NetworkPkg/Application/IpsecConfig/Indexer.c
> +++ b/NetworkPkg/Application/IpsecConfig/Indexer.c
> @@ -1,9 +1,9 @@
> /** @file
>The implementation of construct ENTRY_INDEXER in IpSecConfig application.
>
> - Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
> + Copyright (c) 2009 - 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.
> @@ -42,21 +42,23 @@ ConstructSpdIndexer (
>} else if (ShellCommandLineGetFlag (ParamPackage, L"-d")) {
> ValueStr = ShellCommandLineGetValue (ParamPackage, L"-d");
>} else if (ShellCommandLineGetFlag (ParamPackage, L"-e")) {
> ValueStr = ShellCommandLineGetValue (ParamPackage, L"-e");
>} else {
> -ASSERT (FALSE);
> +return EFI_INVALID_PARAMETER;
>}
>
> - ASSERT (ValueStr != NULL);
> -
> + if (ValueStr == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
>Value64 = StrToUInteger (ValueStr, &Status);
>if (!EFI_ERROR (Status)) {
> Indexer->Index = (UINTN) Value64;
> -Indexer->Name = NULL;
> +ZeroMem (Indexer->Name, MAX_PEERID_LEN);
>} else {
> -UnicodeStrToAsciiStr (ValueStr, (CHAR8 *) Indexer->Name);
> +UnicodeStrToAsciiStrS (ValueStr, (CHAR8 *) Indexer->Name,
> + MAX_PEERID_LEN);
>}
>
>return EFI_SUCCESS;
> }
>
> @@ -87,14 +89,16 @@ ConstructSadIndexer (
>} else if (ShellCommandLineGetFlag (ParamPackage, L"-d")) {
> ValueStr = ShellCommandLineGetValue (ParamPackage, L"-d");
>} else if (ShellCommandLineGetFlag (ParamPackage, L"-e")) {
> ValueStr = ShellCommandLineGetValue (ParamPackage, L"-e");
>} else {
> -ASSERT (FALSE);
> +return EFI_INVALID_PARAMETER;
>}
>
> - ASSERT (ValueStr != NULL);
> + if (ValueStr == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
>
>Value64 = StrToUInteger (ValueStr, &Status);
>if (!EFI_ERROR (Status)) {
> Indexer->Index = (UINTN) Value64;
> ZeroMem (&Indexer->SaId, sizeof (EFI_IPSEC_SA_ID)); @@ -185,14
> +189,16 @@ ConstructPadIndexer (
>} else if (ShellCommandLineGetFlag (ParamPackage, L"-d")) {
> ValueStr = ShellCommandLineGetValue (ParamPackage, L"-d");
>} else if (ShellCommandLineGetFlag (ParamPackage, L"-e")) {
> ValueStr = ShellCommandLineGetValue (ParamPackage, L"-e");
>} else {
> -ASSERT (FALSE);
> +return EFI_INVALID_PARAMETER;
>}
>
> - ASSERT (ValueStr != NULL);
> + if (ValueStr == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
>
>Value64 = StrToUInteger (ValueStr, &Status);
>
>if (!EFI_ERROR (Status)) {
&
Re: [edk2] [PATCH 3/8] NetworkPkg: Replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Star Zeng
> Sent: Wednesday, June 15, 2016 4:44 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin ; Yao,
> Jiewen
> Subject: [edk2] [PATCH 3/8] NetworkPkg: Replace
> UnicodeStrToAsciiStr/AsciiStrToUnicodeStr
>
> It is the follow up of 3ab41b7a325ca11a12b42f5ad1661c4b6791cb49
> to replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr with
> UnicodeStrToAsciiStrS/AsciiStrToUnicodeStrS.
>
> Cc: Jiewen Yao
> Cc: Siyuan Fu
> Cc: Jiaxin Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng
> ---
> .../Application/IpsecConfig/PolicyEntryOperation.c | 6 +-
> NetworkPkg/HttpBootDxe/HttpBootClient.c| 19 +++--
> NetworkPkg/HttpBootDxe/HttpBootConfig.c| 2 +-
> NetworkPkg/HttpDxe/HttpImpl.c | 8 +-
> NetworkPkg/HttpDxe/HttpProto.c | 8 +-
> NetworkPkg/IScsiDxe/IScsiConfig.c | 88
> +++---
> NetworkPkg/IScsiDxe/IScsiDriver.c | 2 +-
> NetworkPkg/IScsiDxe/IScsiMisc.c| 6 +-
> 8 files changed, 87 insertions(+), 52 deletions(-)
>
> diff --git a/NetworkPkg/Application/IpsecConfig/PolicyEntryOperation.c
> b/NetworkPkg/Application/IpsecConfig/PolicyEntryOperation.c
> index 9bbc11490c54..06eb30c091c9 100644
> --- a/NetworkPkg/Application/IpsecConfig/PolicyEntryOperation.c
> +++ b/NetworkPkg/Application/IpsecConfig/PolicyEntryOperation.c
> @@ -271,7 +271,7 @@ CreateSpdEntry (
>//
>ValueStr = ShellCommandLineGetValue (ParamPackage, L"--name");
>if (ValueStr != NULL) {
> -UnicodeStrToAsciiStr (ValueStr, (CHAR8 *) (*Data)->Name);
> +UnicodeStrToAsciiStrS (ValueStr, (CHAR8 *) (*Data)->Name, sizeof
> + ((*Data)->Name));
> *Mask |= NAME;
>}
>
> @@ -785,7 +785,7 @@ CreateSadEntry (
> (*Data)->AlgoInfo.EspAlgoInfo.EncKeyLength = EncKeyLength;
> AsciiStr = AllocateZeroPool (EncKeyLength + 1);
> ASSERT (AsciiStr != NULL);
> -UnicodeStrToAsciiStr (ValueStr, AsciiStr);
> +UnicodeStrToAsciiStrS (ValueStr, AsciiStr, EncKeyLength + 1);
> CopyMem ((*Data)->AlgoInfo.EspAlgoInfo.EncKey, AsciiStr,
> EncKeyLength);
> FreePool (AsciiStr);
> *Mask |= ENCRYPT_KEY;
> @@ -815,7 +815,7 @@ CreateSadEntry (
> (*Data)->AlgoInfo.EspAlgoInfo.AuthKeyLength = AuthKeyLength;
> AsciiStr = AllocateZeroPool (AuthKeyLength + 1);
> ASSERT (AsciiStr != NULL);
> -UnicodeStrToAsciiStr (ValueStr, AsciiStr);
> +UnicodeStrToAsciiStrS (ValueStr, AsciiStr, AuthKeyLength + 1);
> CopyMem ((*Data)->AlgoInfo.EspAlgoInfo.AuthKey, AsciiStr,
> AuthKeyLength);
> FreePool (AsciiStr);
> *Mask |= AUTH_KEY;
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootClient.c
> b/NetworkPkg/HttpBootDxe/HttpBootClient.c
> index e543d9f88303..916f2375c98b 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootClient.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootClient.c
> @@ -255,6 +255,7 @@ HttpBootDhcp6ExtractUriInfo (
>EFI_DHCP6_PACKET_OPTION *Option;
>EFI_IPv6_ADDRESSIpAddr;
>CHAR8 *HostName;
> + UINTN HostNameSize;
>CHAR16 *HostNameStr;
>EFI_STATUS Status;
>
> @@ -349,14 +350,15 @@ HttpBootDhcp6ExtractUriInfo (
> if (EFI_ERROR (Status)) {
>return Status;
> }
> -
> -HostNameStr = AllocateZeroPool ((AsciiStrLen (HostName) + 1) * sizeof
> (CHAR16));
> +
> +HostNameSize = AsciiStrSize (HostName);
> +HostNameStr = AllocateZeroPool (HostNameSize * sizeof (CHAR16));
> if (HostNameStr == NULL) {
>Status = EFI_OUT_OF_RESOURCES;
>goto Error;
> }
>
> -AsciiStrToUnicodeStr (HostName, HostNameStr);
> +AsciiStrToUnicodeStrS (HostName, HostNameStr, HostNameSize);
> Status = HttpBootDns (Private, HostNameStr, &IpAddr);
> FreePool (HostNameStr);
> if (EFI_ERROR (Status)) {
> @@ -752,6 +754,7 @@ HttpBootGetBootFile (
>UINTN ContentLength;
>HTTP_BOOT_CACHE_CONTENT*Cache;
>UINT8 *Block;
> + UINTN UrlSize;
>CHAR16 *Url;
>BOOLEANIdentityMode;
>UINTN ReceivedSize;
> @@ -770,11 +773,12 @@ HttpBootGetBootFile (
>//
>// First, check whether we already cached the requested Uri.
>//
> - Url = AllocatePool ((AsciiStrLen (Private
Re: [edk2] [PATCH v1 1/1] MdePkg: MTftp6: Correct #define value in Mtfp6.h
Reviewed-By: Wu Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > hegdenag > Sent: Thursday, June 16, 2016 12:51 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ; Wu, > Jiaxin > Subject: [edk2] [PATCH v1 1/1] MdePkg: MTftp6: Correct #define value in > Mtfp6.h > > defined values of EFI_MTFTP6_ERRORCODE_ILLEGAL_OPERATION and > EFI_MTFTP6_ERRORCODE_FILE_ALREADY_EXISTS are the same. This patch > corrects the value of EFI_MTFTP6_ERRORCODE_ILLEGAL_OPERATION to 4. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Hegde Nagaraj P > --- > MdePkg/Include/Protocol/Mtftp6.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/MdePkg/Include/Protocol/Mtftp6.h > b/MdePkg/Include/Protocol/Mtftp6.h > index b983660..e0cfc49 100644 > --- a/MdePkg/Include/Protocol/Mtftp6.h > +++ b/MdePkg/Include/Protocol/Mtftp6.h > @@ -4,6 +4,8 @@ >multicast TFTP operations. > >Copyright (c) 2008 - 2011, 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 > @@ -70,7 +72,7 @@ typedef struct _EFI_MTFTP6_TOKEN > EFI_MTFTP6_TOKEN; > /// > /// The MTFTPv6 operation was illegal. > /// > -#define EFI_MTFTP6_ERRORCODE_ILLEGAL_OPERATION 6 > +#define EFI_MTFTP6_ERRORCODE_ILLEGAL_OPERATION 4 > /// > /// The transfer ID is unknown. > /// > -- > 2.8.3.windows.1 > > ___ > 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] [Patch] NetworkPkg: Replace ASSERT with error handling in DnsDxe
Agree. Patch v2 is ready for review.
Thanks.
Jiaxin
> -Original Message-
> From: Ye, Ting
> Sent: Friday, June 17, 2016 5:04 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Zhang, Lubo ; Fu, Siyuan
> Subject: RE: [edk2] [Patch] NetworkPkg: Replace ASSERT with error handling
> in DnsDxe
>
> Jiaxin,
>
> Is it possible to use goto to handle the error cases instead of duplicating
> the
> logic?
>
> Thanks,
> Ting
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Friday, June 17, 2016 2:46 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Zhang, Lubo ; Fu,
> Siyuan
> Subject: [edk2] [Patch] NetworkPkg: Replace ASSERT with error handling in
> DnsDxe
>
> This patch is used to replace ASSERT with error handling in DnsDxe driver.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Zhang Lubo
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> NetworkPkg/DnsDxe/DnsProtocol.c | 34
> ++
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/NetworkPkg/DnsDxe/DnsProtocol.c
> b/NetworkPkg/DnsDxe/DnsProtocol.c index e9101d6..1102fab 100644
> --- a/NetworkPkg/DnsDxe/DnsProtocol.c
> +++ b/NetworkPkg/DnsDxe/DnsProtocol.c
> @@ -110,11 +110,17 @@ Dns4GetModeData (
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4ServerList) {
> Index++;
>}
>DnsModeData->DnsServerCount = (UINT32) Index;
>ServerList = AllocatePool (sizeof (EFI_IPv4_ADDRESS) * DnsModeData-
> >DnsServerCount);
> - ASSERT (ServerList != NULL);
> + if (ServerList == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +Dns4CleanConfigure (&DnsModeData->DnsConfigData);
> +gBS->RestoreTPL (OldTpl);
> +return Status;
> + }
> +
>Index = 0;
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4ServerList) {
> ServerItem = NET_LIST_USER_STRUCT (Entry, DNS4_SERVER_IP,
> AllServerLink);
> CopyMem (ServerList + Index, &ServerItem->Dns4ServerIp, sizeof
> (EFI_IPv4_ADDRESS));
> Index++;
> @@ -128,11 +134,18 @@ Dns4GetModeData (
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4CacheList) {
> Index++;
>}
>DnsModeData->DnsCacheCount = (UINT32) Index;
>CacheList = AllocatePool (sizeof (EFI_DNS4_CACHE_ENTRY) *
> DnsModeData->DnsCacheCount);
> - ASSERT (CacheList != NULL);
> + if (CacheList == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +Dns4CleanConfigure (&DnsModeData->DnsConfigData);
> +FreePool (ServerList);
> +gBS->RestoreTPL (OldTpl);
> +return Status;
> + }
> +
>Index =0;
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns4CacheList) {
> CacheItem = NET_LIST_USER_STRUCT (Entry, DNS4_CACHE, AllCacheLink);
> CopyMem (CacheList + Index, &CacheItem->DnsCache, sizeof
> (EFI_DNS4_CACHE_ENTRY));
> Index++;
> @@ -931,11 +944,17 @@ Dns6GetModeData (
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6ServerList) {
> Index++;
>}
>DnsModeData->DnsServerCount = (UINT32) Index;
>ServerList = AllocatePool (sizeof(EFI_IPv6_ADDRESS) * DnsModeData-
> >DnsServerCount);
> - ASSERT (ServerList != NULL);
> + if (ServerList == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +Dns6CleanConfigure (&DnsModeData->DnsConfigData);
> +gBS->RestoreTPL (OldTpl);
> +return Status;
> + }
> +
>Index = 0;
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6ServerList) {
> ServerItem = NET_LIST_USER_STRUCT (Entry, DNS6_SERVER_IP,
> AllServerLink);
> CopyMem (ServerList + Index, &ServerItem->Dns6ServerIp, sizeof
> (EFI_IPv6_ADDRESS));
> Index++;
> @@ -949,11 +968,18 @@ Dns6GetModeData (
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6CacheList) {
> Index++;
>}
>DnsModeData->DnsCacheCount = (UINT32) Index;
>CacheList = AllocatePool (sizeof(EFI_DNS6_CACHE_ENTRY) *
> DnsModeData->DnsCacheCount);
> - ASSERT (CacheList != NULL);
> + if (CacheList == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +Dns6CleanConfigure (&DnsModeData->DnsConfigData);
> +FreePool (ServerList);
> +gBS->RestoreTPL (OldTpl);
> +return Status;
> + }
> +
>Index =0;
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &mDriverData->Dns6CacheList) {
> CacheItem = NET_LIST_USER_STRUCT (Entry, DNS6_CACHE, AllCacheLink);
> CopyMem (CacheList + Index, &CacheItem->DnsCache, sizeof
> (EFI_DNS6_CACHE_ENTRY));
> Index++;
> --
> 1.9.5.msysgit.1
>
> ___
> 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] [patch] NetworkPkg: Replace ASSERT with error handling in Http boot and IScsi
Hi Lubo,
Two comments as below:
1. In IScsiFormExtractConfig(), you need free IfrNvData and InitiatorName pool
first before return EFI_OUT_OF_RESOURCES.
2. In IScsiGetConfigData(), returning EFI_OUT_OF_RESOURCES may be incorrect
after HiiSetString() failed? Should be "continue"?
Thanks.
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Zhang Lubo
> Sent: Friday, June 17, 2016 4:46 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [edk2] [patch] NetworkPkg: Replace ASSERT with error handling in
> Http boot and IScsi
>
> This patch is used to replace ASSERT with error handling in Http boot Driver
> and IScsi driver.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo
> ---
> NetworkPkg/HttpBootDxe/HttpBootConfig.c | 5 +++--
> NetworkPkg/HttpBootDxe/HttpBootDhcp6.c | 5 -
> NetworkPkg/IScsiDxe/IScsiConfig.c | 6 --
> NetworkPkg/IScsiDxe/IScsiDriver.c | 1 +
> NetworkPkg/IScsiDxe/IScsiMisc.c | 5 -
> NetworkPkg/IScsiDxe/IScsiProto.c| 17 +
> 6 files changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> index 04c2f3e..3708995 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> @@ -271,11 +271,13 @@ HttpBootFormExtractConfig (
> // followed by "&OFFSET=0&WIDTH="
> followed by a Null-terminator
> //
> ConfigRequestHdr = HiiConstructConfigHdr (&gHttpBootConfigGuid,
> mHttpBootConfigStorageName, CallbackInfo->ChildHandle);
> Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
> ConfigRequest = AllocateZeroPool (Size);
> -ASSERT (ConfigRequest != NULL);
> +if (ConfigRequest == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> AllocatedRequest = TRUE;
> UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX",
> ConfigRequestHdr, (UINT64)BufferSize);
> FreePool (ConfigRequestHdr);
>}
>
> @@ -462,11 +464,10 @@ HttpBootFormCallback (
>case KEY_INITIATOR_URI:
> //
> // Get user input URI string
> //
> Uri = HiiGetString (CallbackInfo->RegisteredHandle, Value->string, NULL);
> -ASSERT (Uri != NULL);
> if (Uri == NULL) {
>return EFI_UNSUPPORTED;
> }
>
> //
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> index 0157095..9ea421d 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> @@ -399,10 +399,11 @@ HttpBootCacheDhcp6Offer (
>
>@retval EFI_SUCCESS Told the EFI DHCPv6 Protocol driver to
> continue
> the DHCP process.
>@retval EFI_NOT_READY Only used in the Dhcp6Selecting state. The
> EFI
> DHCPv6 Protocol
> driver will continue to wait for more
> packets.
>@retval EFI_ABORTED Told the EFI DHCPv6 Protocol driver to abort
> the
> current process.
> + @retval EFI_OUT_OF_RESOURCES There are not enough resources.
>
> **/
> EFI_STATUS
> EFIAPI
> HttpBootDhcp6CallBack (
> @@ -449,11 +450,13 @@ HttpBootDhcp6CallBack (
> Status = EFI_ABORTED;
> } else {
> ASSERT (NewPacket != NULL);
> SelectAd = &Private->OfferBuffer[Private->SelectIndex -
> 1].Dhcp6.Packet.Offer;
> *NewPacket = AllocateZeroPool (SelectAd->Size);
> - ASSERT (*NewPacket != NULL);
> + if (*NewPacket == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> + }
> CopyMem (*NewPacket, SelectAd, SelectAd->Size);
> }
> break;
>
> default:
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c
> b/NetworkPkg/IScsiDxe/IScsiConfig.c
> index 69a4003..bd24de2 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
> @@ -1,9 +1,9 @@
> /** @file
>Helper functions for configuring or getting the parameters relating to
> iSCSI.
>
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 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-lice
Re: [edk2] [PATCH v2] NetworkPkg: Replace ASSERT with error handling in Http boot and IScsi
Looks good to me.
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: Zhang, Lubo
> Sent: Monday, June 20, 2016 1:57 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [PATCH v2] NetworkPkg: Replace ASSERT with error handling in Http
> boot and IScsi
>
> v2:
> *Fix some memory leak issue.
>
> This patch is used to replace ASSERT with error handling in Http boot Driver
> and IScsi driver.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo
> ---
> NetworkPkg/HttpBootDxe/HttpBootConfig.c | 5 +++--
> NetworkPkg/HttpBootDxe/HttpBootDhcp6.c | 5 -
> NetworkPkg/IScsiDxe/IScsiConfig.c | 8 ++--
> NetworkPkg/IScsiDxe/IScsiDriver.c | 1 +
> NetworkPkg/IScsiDxe/IScsiMisc.c | 5 -
> NetworkPkg/IScsiDxe/IScsiProto.c| 17 +
> 6 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> index 04c2f3e..3708995 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
> @@ -271,11 +271,13 @@ HttpBootFormExtractConfig (
> // followed by "&OFFSET=0&WIDTH="
> followed by a Null-terminator
> //
> ConfigRequestHdr = HiiConstructConfigHdr (&gHttpBootConfigGuid,
> mHttpBootConfigStorageName, CallbackInfo->ChildHandle);
> Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
> ConfigRequest = AllocateZeroPool (Size);
> -ASSERT (ConfigRequest != NULL);
> +if (ConfigRequest == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> AllocatedRequest = TRUE;
> UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX",
> ConfigRequestHdr, (UINT64)BufferSize);
> FreePool (ConfigRequestHdr);
>}
>
> @@ -462,11 +464,10 @@ HttpBootFormCallback (
>case KEY_INITIATOR_URI:
> //
> // Get user input URI string
> //
> Uri = HiiGetString (CallbackInfo->RegisteredHandle, Value->string, NULL);
> -ASSERT (Uri != NULL);
> if (Uri == NULL) {
>return EFI_UNSUPPORTED;
> }
>
> //
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> index 0157095..9ea421d 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
> @@ -399,10 +399,11 @@ HttpBootCacheDhcp6Offer (
>
>@retval EFI_SUCCESS Told the EFI DHCPv6 Protocol driver to
> continue
> the DHCP process.
>@retval EFI_NOT_READY Only used in the Dhcp6Selecting state. The
> EFI
> DHCPv6 Protocol
> driver will continue to wait for more
> packets.
>@retval EFI_ABORTED Told the EFI DHCPv6 Protocol driver to abort
> the
> current process.
> + @retval EFI_OUT_OF_RESOURCES There are not enough resources.
>
> **/
> EFI_STATUS
> EFIAPI
> HttpBootDhcp6CallBack (
> @@ -449,11 +450,13 @@ HttpBootDhcp6CallBack (
> Status = EFI_ABORTED;
> } else {
> ASSERT (NewPacket != NULL);
> SelectAd = &Private->OfferBuffer[Private->SelectIndex -
> 1].Dhcp6.Packet.Offer;
> *NewPacket = AllocateZeroPool (SelectAd->Size);
> - ASSERT (*NewPacket != NULL);
> + if (*NewPacket == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> + }
> CopyMem (*NewPacket, SelectAd, SelectAd->Size);
> }
> break;
>
> default:
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c
> b/NetworkPkg/IScsiDxe/IScsiConfig.c
> index 69a4003..8f06a07 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
> @@ -1,9 +1,9 @@
> /** @file
>Helper functions for configuring or getting the parameters relating to
> iSCSI.
>
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 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
>
> @@ -1957,11 +1957,15 @@ IScsiFormExtractConfig (
> // followed by "&OFFSET=0&WIDTH="
> followed by a Null-terminator
> //
> ConfigRequestHdr = HiiConstructConfigHdr (&gIScsi
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Hi Ryan, Feedback see below: Thanks and Best Regards! Jiaxin > -Original Message- > From: Ryan Harkin [mailto:ryan.har...@linaro.org] > Sent: Tuesday, June 21, 2016 2:09 AM > To: Wu, Jiaxin > Cc: edk2-devel-01 ; Ye, Ting ; > Fu, Siyuan > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > config policy > > Hi Jiaxin, > > Ever since this patch (below), I've been having problems with DHCP on my > boards. > > I've isolated the problem and can reproduce it every time now. > > If I allow the board to auto boot, it tries to PXE boot, fails (I've stopped > my > TFTP server on purpose to trigger the failure), drops to shell. Since you stop the TFTP server, I suppose this failure is expected. > > Booting EFI Network > ..PXE-E99: Unexpected network error. > Booting EFI Internal Shell > > Then I use this command to configure eth0 as dhcp: > > Shell> ifconfig -s eth0 dhcp > > I am also using this command to set eth0 as static: > > Shell> ifconfig -s eth0 static 192.168.1.31 255.255.255.0 192.168.1.1 > > On first boot, DHCP works from the shell. (First boot == empty var store) On > second and subsequent boots, DHCP fails. What does this failure mean? DHCP DORA is not triggered? If so, I think it's normal because you have gotten an IP address by previous DHCP. If you want to reset this IP address, you can use the command of " ifconfig -r eth0 ". > If I use configure eth0 static, then DHCP, it works again. Yes, static->DHCP will trigger a new DHCP process(DORA). > > If I interrupt the boot sequence so that it doesn't attempt to PXE boot and > simply run the shell, DHCP works every time. Yes, DHCP should work due to the policy has been changed to DHCP (ifconfig -s eth0 dhcp). Once with DHCP policy, the platform will try to get the IP by DHCP after you reset the platform. > > I don't believe this is the solution to the problem, but working out what part > of the patch causes the problem for me show that if I remove the SetData > call from IpDriver.c, ln 592, then DHCP works every time. > > PXE boot works for me with or without the SetData call in place. Here, SetData can't be removed because the default IP configure data need to be set after IP driver started (This default data can be changed by other drivers). You remove it, then DHCP works every time because the default DHCP policy is not set in IP driver but you set it manually through ifconfig tool. This is not the behavior we want. Current design rules is that once the DHCP successed, it won't try to obtain a new address from DHCP(This is why "ifconfig -s eth0 dhcp" not work). But you can refresh it though " ifconfig -r eth0 ". > > I've been trying to debug the problem and review the code to work out why > it's failing, but I'm not getting very far. > > Are you (or is anyone else) able to explain why this is going wrong in such a > predictable way? Can you reproduce the behaviour on your systems? > > Is there anything you'd like me to try to isolate the real problem? > > Thanks, > Ryan. > > > On 25 February 2016 at 04:22, Jiaxin Wu wrote: > > Git version '3d0a49ad' commit provided a scenario to resolve the > > performance issue for IPv4, but it's not workable for IPv6. To avoid > > IPv4 and IPv6 inconsistency, we decided to revert that version fix. > > > > If so, the default policy for Ip4Config2 is Ip4Config2PolicyDhcp, > > which results in all NIC ports attempting DHCP. So, this patch is used > > to changes the the default IPv4 config policy to > > Ip4Config2PolicyStatic and also defer the SetData operation after > > Ip4Config2Protocol installed. This update let the other platform > > drivers have chance to change the default config data by consume > > Ip4Config2Protocol. > > > > Cc: Subramanian Sriram > > Cc: El-Haj-Mahmoud Samer > > Cc: Ye Ting > > Cc: Fu Siyuan > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Jiaxin Wu > > --- > > .../Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 76 +--- > -- > > .../Universal/Network/Ip4Dxe/Ip4Config2Impl.h | 36 - > > MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 57 > +- > > MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf | 2 +- > > MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 90 ++- > --- > > 5 files changed, 155 insertions(+), 106 deletions(-) > > > > diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c > > b/MdeModulePkg/Universal/Network
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Hi Ryan, First, I want confirm with you that which version code do you used? Edk2 latest one? If not, I strongly recommend to update it. https://github.com/tianocore/edk2.git Based on the latest edk2 code, the IPv4 address used in PXE (got from DHCP process) won't be assigned to NIC interface after PXE boot. So, there is no IP address assigned to eth0. But with the command of "ifconfig -s eth0 dhcp" in shell, there should be a temporary IPv4 address assigned to eth0 and the policy change to DHCP. After you retry the PXE boot, the policy will change to static again (PXE set it to static) and no IP address assigned to eth0. This is an expected behavior. Now, below are the steps and the result I tried according your description: 1. Stop the PXE server; 2. Boot PXE option failed ,then boot to shell;> ifconfig -l eth0, no IP address, policy is static. 3. In shell, Enter the command "ifconfig -s eth0 dhcp" to set the policy to DHCP> ifconfig -l eth0, have an IP address, policy is dhcp. 4. Enter the command "ifconfig -s eth0 static 192.168.1.31 255.255.255.0 192.168.1.1" to change the policy to static;> ifconfig -l eth0, have an IP address 192.168.1.31, policy is static. 5. Try PXE boot failed again ,then boot to shell;> ifconfig -l eth0, have an IP address 192.168.1.31, policy is static. 6. Enter the command "ifconfig -s eth0 dhcp" to set the policy to DHCP > ifconfig -l eth0, have an IP address, policy is dhcp. Thanks. Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ryan Harkin > Sent: Tuesday, June 21, 2016 2:33 PM > To: Wu, Jiaxin > Cc: Ye, Ting ; Fu, Siyuan ; edk2- > devel-01 > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > config policy > > On 21 Jun 2016 04:43, "Wu, Jiaxin" wrote: > > > > Hi Ryan, > > > > Feedback see below: > > > > Thanks and Best Regards! > > Jiaxin > > > > > -Original Message- > > > From: Ryan Harkin [mailto:ryan.har...@linaro.org] > > > Sent: Tuesday, June 21, 2016 2:09 AM > > > To: Wu, Jiaxin > > > Cc: edk2-devel-01 ; Ye, Ting > > > >; > > > Fu, Siyuan > > > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default > > > IPv4 config policy > > > > > > Hi Jiaxin, > > > > > > Ever since this patch (below), I've been having problems with DHCP > > > on my boards. > > > > > > I've isolated the problem and can reproduce it every time now. > > > > > > If I allow the board to auto boot, it tries to PXE boot, fails (I've > stopped my > > > TFTP server on purpose to trigger the failure), drops to shell. > > > > Since you stop the TFTP server, I suppose this failure is expected. > > > > > > Correct, I did it on purpose so I could reproduce this bug. > > > > > > > > > Booting EFI Network > > > ..PXE-E99: Unexpected network error. > > > Booting EFI Internal Shell > > > > > > Then I use this command to configure eth0 as dhcp: > > > > > > Shell> ifconfig -s eth0 dhcp > > > > > > I am also using this command to set eth0 as static: > > > > > > Shell> ifconfig -s eth0 static 192.168.1.31 255.255.255.0 > > > 192.168.1.1 > > > > > > On first boot, DHCP works from the shell. (First boot == empty var > store) On > > > second and subsequent boots, DHCP fails. > > > > What does this failure mean? DHCP DORA is not triggered? > > I don't know what DORA means, sorry. > > But I meant that on boot, there is no IP address assigned to eth0 and running > "ifconfig -s eth0 dhcp" fails to get an IP address. > > > If so, I think it's normal because you have gotten an IP address by > previous DHCP. > > No, I only got an IP address on the previous boot, not on this boot. > > > If you want to reset this IP address, you can use the command of " > ifconfig -r eth0 ". > > > > > > I'll try that, but I don't expect it to work because I DHCP doesn't appear to > be > working at all. > > From what I can tell, PXE Boot in Intel BDS is setting the IPv4 policy to > static > and that appears to cause some problems. I assume it sets the port back to > DHCP again, or else it wouldn't work, but I haven't successfully traced that. > > > > > > If I use configure eth0 static, then DHCP, it works again. > > > > Yes, static->
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Hi Ryan, I can't reproduce your issue on NT32, I will try it in a real platform later. > On first boot, policy is static, it gets changed to DHCP, "ifconfig -s > eth0 dhcp" works. On reboot, policy is dhcp, PXE changes it a couple > of times, then drops to the shell with is set to static again. > "ifconfig -s eth0 dhcp" fails no matter how many times I reboot. First PXE boot --> ifconfig -s eth0 dhcp (Success) --> reboot, then PXE --> ifconfig -s eth0 dhcp (Your platform failed here, but my parts is always in a success no matter how many times I tried.) > It's only when I "ifconfig -s eth0 static " then "ifconfig -s eth0 dhcp" > that > DHCP obtains an IP address again. > > It could easily be a bug in the LAN9118 driver too, but there's a bug > somewhere, because it isn't working as we expect :-O So, to help us analyze problem, could you sent me one wireshark packet for the above steps? Thanks and Best Regards! Jiaxin > -Original Message----- > From: Ryan Harkin [mailto:ryan.har...@linaro.org] > Sent: Tuesday, June 21, 2016 5:32 PM > To: Wu, Jiaxin > Cc: Ye, Ting ; Fu, Siyuan ; edk2- > devel-01 > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > config policy > > Hi Jiaxin, > > Thanks for spending time investigating this, I appreciate it. > > > On 21 June 2016 at 09:46, Wu, Jiaxin wrote: > > Hi Ryan, > > > > First, I want confirm with you that which version code do you used? Edk2 > latest one? If not, I strongly recommend to update it. > > https://github.com/tianocore/edk2.git > > > > I'm using recent code, this is the commit I'm based on: > > d8d217c 2016-06-16 MdePkg: MTftp6: Correct #define value in Mtfp6.h > [hegdenag] > > I see there are a few more recent commits, some of them in NetworkPkg, so > I'll rebase to the very latest again, although I don't expect it will solve my > problem. > > > > Based on the latest edk2 code, the IPv4 address used in PXE (got from > DHCP process) won't be assigned to NIC interface after PXE boot. > > Yes, that's what I expected. > > > > > So, there is no IP address assigned to eth0. But with the command of > "ifconfig -s eth0 dhcp" in shell, there should be a temporary IPv4 address > assigned to eth0 and the policy change to DHCP. > > > > That's what is failing after the first boot. > > On first boot, policy is static, it gets changed to DHCP, "ifconfig -s > eth0 dhcp" works. On reboot, policy is dhcp, PXE changes it a couple > of times, then drops to the shell with is set to static again. > "ifconfig -s eth0 dhcp" fails no matter how many times I reboot. > > It's only when I "ifconfig -s eth0 static " then "ifconfig -s eth0 dhcp" > that > DHCP obtains an IP address again. > > It could easily be a bug in the LAN9118 driver too, but there's a bug > somewhere, because it isn't working as we expect :-O > > > > After you retry the PXE boot, the policy will change to static again (PXE > > set it > to static) and no IP address assigned to eth0. This is an expected behavior. > > > > Yes, I see that. > > > > Now, below are the steps and the result I tried according your description: > > 1. Stop the PXE server; > > 2. Boot PXE option failed ,then boot to shell;> ifconfig -l > > eth0, no IP > address, policy is static. > > 3. In shell, Enter the command "ifconfig -s eth0 dhcp" to set the policy to > DHCP> ifconfig -l eth0, have an IP address, policy is dhcp. > > Yes, this works for me on first boot. > > > > 4. Enter the command "ifconfig -s eth0 static 192.168.1.31 255.255.255.0 > 192.168.1.1" to change the policy to static;> ifconfig -l eth0, > have an > IP address 192.168.1.31, policy is static. > > 5. Try PXE boot failed again ,then boot to shell;--------> ifconfig -l > > eth0, > have an IP address 192.168.1.31, policy is static. > > I haven't tried PXE boot without rebooting, I should try that also... > > > > 6. Enter the command "ifconfig -s eth0 dhcp" to set the policy to DHCP > > > > ifconfig -l eth0, have an IP address, policy is dhcp. > > > > > > Thanks. > > Jiaxin > > > > > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > >> Of Ryan Harkin > >> Sent: Tuesday, June 21, 2016 2:33 PM > >> To: Wu, Jiax
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Ryan, > There could be a bug here, I suppose. Why is NetLibCreateServiceChild > returning EFI_UNSUPPORTED? I guess I need to investigate this some more. > > Continuing, at this point Status is still EFI_UNSUPPORTED, so this is caught > line 958 and we return from the function. That looks like a bug. If not, it > could do with a comment explaining why we've just handled the > EFI_UNSUPPORTED error without returning, yet we return here anyway. Ip4Dxe driver will try to get one IP address from DHCP server automatically if policy is DHCP, so DHCPv4 Service Binding protocol is required for this operation. If DHCPv4 Service Binding protocol is not ready, the Ip4Dxe should register a notify to wait this Service Binding protocol ready. We can't guarantee DHCPv4 Service has been started before Ip4 Service. So, EFI_UNSUPPORTED status check for NetLibCreateServiceChild is reasonable and correct here. According your below test patch, you allow Ip4StartAutoConfig() function continue the steps even DHCPv4 Service is not ready, this is not allowed because no DHCP instance has been created, then ASSERT happened. You don't need to do that. You can see the Ip4Config2OnDhcp4SbInstalled() notify function, once the DHCPv4 service binding protocol is installed in the system, Ip4StartAutoConfig() will be recalled again. > > I don't have wireshark set up, but I'll try to get it working and send > > you a trace. > > > > However, I suspect that DHCP service (Is that the DORA you mentioned?) > > is not being restarted for some reason, so in that case, no packets > > would be sent out. For this confusion, the packet captured from wireshark can help us know whether there is any packet out or not. Thanks. Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ryan Harkin > Sent: Wednesday, June 22, 2016 2:12 AM > To: Wu, Jiaxin > Cc: Ye, Ting ; Fu, Siyuan ; edk2- > devel-01 > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > config policy > > Hi Jiaxin, > > On 21 June 2016 at 12:20, Ryan Harkin wrote: > > Hi Jiaxin, > > > > On 21 June 2016 at 12:10, Wu, Jiaxin wrote: > >> Hi Ryan, > >> > >> I can't reproduce your issue on NT32, I will try it in a real platform > >> later. > >> > > > > I am unable to reproduce the problem on my "FVP models" (a type of > > emulator) either. The models use a different ethernet device than my > > hardware. > > > > > >>> On first boot, policy is static, it gets changed to DHCP, "ifconfig -s > >>> eth0 dhcp" works. On reboot, policy is dhcp, PXE changes it a couple > >>> of times, then drops to the shell with is set to static again. > >>> "ifconfig -s eth0 dhcp" fails no matter how many times I reboot. > >> > >> First PXE boot --> ifconfig -s eth0 dhcp (Success) --> reboot, then > >> PXE --> ifconfig -s eth0 dhcp (Your platform failed here, but my > >> parts is always in a success no matter how many times I tried.) > >> > >>> It's only when I "ifconfig -s eth0 static " then "ifconfig -s > >>> eth0 dhcp" that DHCP obtains an IP address again. > >>> > >>> It could easily be a bug in the LAN9118 driver too, but there's a > >>> bug somewhere, because it isn't working as we expect :-O > >> > >> So, to help us analyze problem, could you sent me one wireshark packet > for the above steps? > >> > > > > I don't have wireshark set up, but I'll try to get it working and send > > you a trace. > > > > However, I suspect that DHCP service (Is that the DORA you mentioned?) > > is not being restarted for some reason, so in that case, no packets > > would be sent out. > > > > I don't know how the DHCP service is handled or started, but I'll try > > and find the points in the code where it's started and stopped and add > > some trace to see if there are any errors. Any suggestions of where > > to place some DEBUG would be welcome. > > > > I decided to add DEBUG statements to function Ip4StartAutoConfig in > Ip4Config2Impl.c. I appended my DEBUG to the end of each line, so I didn't > change the line numbering when compared to the upstream version, > currently last modified here: > 364f4efa444150df3f074f563374dce1e153adc6 > > The debug code I added to each branch in the function looks like this: > > DEBUG ((EFI_D_ERROR, "%a:%d Instance->Policy=%d\n", __FUNCTION__, > __LINE__, Ins
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Hi Ryan, I can reproduce the issue on my real platform now, thank you for your reporting. I will find the root cause and fix it. If have any process, I will inform you. Thanks again. Jiaxin > -Original Message- > From: Wu, Jiaxin > Sent: Wednesday, June 22, 2016 10:41 AM > To: Ryan Harkin > Cc: Ye, Ting ; Fu, Siyuan ; edk2- > devel-01 > Subject: RE: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > config policy > > Ryan, > > > There could be a bug here, I suppose. Why is NetLibCreateServiceChild > > returning EFI_UNSUPPORTED? I guess I need to investigate this some > more. > > > > Continuing, at this point Status is still EFI_UNSUPPORTED, so this is > > caught line 958 and we return from the function. That looks like a > > bug. If not, it could do with a comment explaining why we've just > > handled the EFI_UNSUPPORTED error without returning, yet we return > here anyway. > > Ip4Dxe driver will try to get one IP address from DHCP server automatically if > policy is DHCP, so DHCPv4 Service Binding protocol is required for this > operation. If DHCPv4 Service Binding protocol is not ready, the Ip4Dxe should > register a notify to wait this Service Binding protocol ready. We can't > guarantee DHCPv4 Service has been started before Ip4 Service. So, > EFI_UNSUPPORTED status check for NetLibCreateServiceChild is reasonable > and correct here. > According your below test patch, you allow Ip4StartAutoConfig() function > continue the steps even DHCPv4 Service is not ready, this is not allowed > because no DHCP instance has been created, then ASSERT happened. You > don't need to do that. You can see the Ip4Config2OnDhcp4SbInstalled() > notify function, once the DHCPv4 service binding protocol is installed in the > system, Ip4StartAutoConfig() will be recalled again. > > > > I don't have wireshark set up, but I'll try to get it working and > > > send you a trace. > > > > > > However, I suspect that DHCP service (Is that the DORA you > > > mentioned?) is not being restarted for some reason, so in that case, > > > no packets would be sent out. > > For this confusion, the packet captured from wireshark can help us know > whether there is any packet out or not. > > Thanks. > Jiaxin > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Ryan Harkin > > Sent: Wednesday, June 22, 2016 2:12 AM > > To: Wu, Jiaxin > > Cc: Ye, Ting ; Fu, Siyuan ; > > edk2- > > devel-01 > > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > > config policy > > > > Hi Jiaxin, > > > > On 21 June 2016 at 12:20, Ryan Harkin wrote: > > > Hi Jiaxin, > > > > > > On 21 June 2016 at 12:10, Wu, Jiaxin wrote: > > >> Hi Ryan, > > >> > > >> I can't reproduce your issue on NT32, I will try it in a real platform > > >> later. > > >> > > > > > > I am unable to reproduce the problem on my "FVP models" (a type of > > > emulator) either. The models use a different ethernet device than > > > my hardware. > > > > > > > > >>> On first boot, policy is static, it gets changed to DHCP, "ifconfig -s > > >>> eth0 dhcp" works. On reboot, policy is dhcp, PXE changes it a couple > > >>> of times, then drops to the shell with is set to static again. > > >>> "ifconfig -s eth0 dhcp" fails no matter how many times I reboot. > > >> > > >> First PXE boot --> ifconfig -s eth0 dhcp (Success) --> reboot, then > > >> PXE --> ifconfig -s eth0 dhcp (Your platform failed here, but my > > >> parts is always in a success no matter how many times I tried.) > > >> > > >>> It's only when I "ifconfig -s eth0 static " then "ifconfig -s > > >>> eth0 dhcp" that DHCP obtains an IP address again. > > >>> > > >>> It could easily be a bug in the LAN9118 driver too, but there's a > > >>> bug somewhere, because it isn't working as we expect :-O > > >> > > >> So, to help us analyze problem, could you sent me one wireshark > > >> packet > > for the above steps? > > >> > > > > > > I don't have wireshark set up, but I'll try to get it working and > > > send you a trace. > > > > > > However, I suspect that DHCP service (Is that the DORA you > > >
Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy
Hi Ryan, I have root cause the issue: Let me analyze this problem for you according below steps: 1 .First PXE boot, then boot to shell; 2. ifconfig -s eth0 dhcp (Success); 3. Reboot and do PXE, then boot to shell;> The issue is enrolled by here On this reboot, policy is DHCP (Changed by step2). So, Ip4Dxe driver will try to get one IP address from DHCP server automatically. Before it get the IP address successfully, the IpSb->State will be always in IP4_SERVICE_STARTED status until the Instance->Dhcp4Event is triggered, then it can be changed to IP4_SERVICE_CONFIGED. But the DHCP process will be interrupted by PXE boot, which will change the policy to static, and the Instance->Dhcp4Event will be also closed directly. However, current implementation doesn't update the IpSb->State to IP4_SERVICE_UNSTARTED status in such case. So, failure happened! Why not happened in simulator platform? Because Ip4Dxe driver finished the DHCP process (DORA) and the IpSb->State has been changed to IP4_SERVICE_CONFIGED before PXE set the policy to DHCP. 4. ifconfig -s eth0 dhcp (Platform failed to get IP address no matter how many times retried.) The corresponding patch will be send out later to fix this issue, so, please help to verify it. Thanks and Best Regard! Jiaxin > -Original Message- > From: Wu, Jiaxin > Sent: Wednesday, June 22, 2016 11:35 AM > To: 'Ryan Harkin' > Cc: Ye, Ting ; Fu, Siyuan ; 'edk2- > devel-01' > Subject: RE: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > config policy > > Hi Ryan, > I can reproduce the issue on my real platform now, thank you for your > reporting. I will find the root cause and fix it. If have any process, I will > inform > you. > > Thanks again. > Jiaxin > > > -Original Message- > > From: Wu, Jiaxin > > Sent: Wednesday, June 22, 2016 10:41 AM > > To: Ryan Harkin > > Cc: Ye, Ting ; Fu, Siyuan ; > > edk2- > > devel-01 > > Subject: RE: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 > > config policy > > > > Ryan, > > > > > There could be a bug here, I suppose. Why is > > > NetLibCreateServiceChild returning EFI_UNSUPPORTED? I guess I need > > > to investigate this some > > more. > > > > > > Continuing, at this point Status is still EFI_UNSUPPORTED, so this > > > is caught line 958 and we return from the function. That looks like > > > a bug. If not, it could do with a comment explaining why we've just > > > handled the EFI_UNSUPPORTED error without returning, yet we return > > here anyway. > > > > Ip4Dxe driver will try to get one IP address from DHCP server > > automatically if policy is DHCP, so DHCPv4 Service Binding protocol is > > required for this operation. If DHCPv4 Service Binding protocol is not > > ready, the Ip4Dxe should register a notify to wait this Service > > Binding protocol ready. We can't guarantee DHCPv4 Service has been > > started before Ip4 Service. So, EFI_UNSUPPORTED status check for > > NetLibCreateServiceChild is reasonable and correct here. > > According your below test patch, you allow Ip4StartAutoConfig() > > function continue the steps even DHCPv4 Service is not ready, this is > > not allowed because no DHCP instance has been created, then ASSERT > > happened. You don't need to do that. You can see the > > Ip4Config2OnDhcp4SbInstalled() notify function, once the DHCPv4 > > service binding protocol is installed in the system, Ip4StartAutoConfig() > > will > be recalled again. > > > > > > I don't have wireshark set up, but I'll try to get it working and > > > > send you a trace. > > > > > > > > However, I suspect that DHCP service (Is that the DORA you > > > > mentioned?) is not being restarted for some reason, so in that > > > > case, no packets would be sent out. > > > > For this confusion, the packet captured from wireshark can help us > > know whether there is any packet out or not. > > > > Thanks. > > Jiaxin > > > > > > > -Original Message- > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > > Of Ryan Harkin > > > Sent: Wednesday, June 22, 2016 2:12 AM > > > To: Wu, Jiaxin > > > Cc: Ye, Ting ; Fu, Siyuan ; > > > edk2- > > > devel-01 > > > Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default > > > IPv4 config policy > > > > > > Hi Jiaxin, > > > > > > On 21 June 2016 at 12:20, Ryan Harkin wrote: > > > >
Re: [edk2] [Patch] MdeModulePkg: Fix the wrong IpSb->State update
> -Original Message-
> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> Sent: Wednesday, June 22, 2016 8:00 PM
> To: Wu, Jiaxin
> Cc: edk2-devel-01 ; Ye, Ting ;
> Fu, Siyuan
> Subject: Re: [Patch] MdeModulePkg: Fix the wrong IpSb->State update
>
> On 22 June 2016 at 12:14, Jiaxin Wu wrote:
> > This patch is used to fix the wrong IpSb->State update issue.
> >
> > Issue reproduce steps:
> > 1 .First PXE boot, then boot to shell; 2. ifconfig -s eth0 dhcp
> > (Success); 3. Reboot and do PXE, then boot to shell; 4. ifconfig -s
> > eth0 dhcp (Platform failed to get IP address no matter
> >how many times retried.)
> >
> > Root cause:
> > On step3 reboot, policy is DHCP (Changed by step2). So, Ip4Dxe driver
> > will try to get one IP address from DHCP server automatically. Before
> > it get the IP address successfully, the IpSb->State will be always in
> > IP4_SERVICE_STARTED status until the Instance->Dhcp4Event is
> > triggered, then it can be changed to IP4_SERVICE_CONFIGED. But the
> > DHCP process will be interrupted by PXE boot, which will change the
> > policy to static, and the Instance->Dhcp4Event will be also closed
> > directly. However, current implementation doesn't update the
> > IpSb->State to IP4_SERVICE_UNSTARTED status in such case. So, failure
> happened.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Ryan Harkin
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiaxin Wu
>
> I tested this on Juno ARM Development Platform and it now works as
> expected.
Thanks your verification.
>
> I still have a problem with Versatile Express TC2 that is fixed by reverting
> commit 7648748e99eeeadec38fda7568adb260c4acc861, however it is a
> different problem than the one fixed in this patch. I'll investigate that
> further
> and report back if/when I find out more.
Welcome your any feedback:).
>
> Reviewed-by: Ryan Harkin
> Tested-by: Ryan Harkin
>
> > ---
> > MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> > b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> > index d0fa132..10d7181 100644
> > --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> > +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
> > @@ -140,11 +140,11 @@ Ip4Config2OnPolicyChanged (
> >IpSb->DefaultInterface = IpIf;
> >InsertHeadList (&IpSb->Interfaces, &IpIf->Link);
> >IpSb->DefaultRouteTable = RouteTable;
> >Ip4ReceiveFrame (IpIf, NULL, Ip4AccpetFrame, IpSb);
> >
> > - if (IpSb->State == IP4_SERVICE_CONFIGED) {
> > + if (IpSb->State == IP4_SERVICE_CONFIGED || IpSb->State ==
> > + IP4_SERVICE_STARTED) {
> > IpSb->State = IP4_SERVICE_UNSTARTED;
> >}
> >
> >//
> >// Start the dhcp configuration.
> > --
> > 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] [edk2-staging/HTTPS-TLS][PATCH]: Initialize handshake ret variable
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: Thomas Palmer [mailto:thomas.pal...@hpe.com]
> Sent: Wednesday, June 22, 2016 9:57 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; samer.el-haj-mahm...@hpe.com;
> Thomas Palmer
> Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Initialize handshake ret
> variable
>
> Initialize the variable that holds the return from SSL_do_handshake.
> When the handshake function is not called it will be uninitialized.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Thomas Palmer
> ---
> CryptoPkg/Library/TlsLib/TlsLib.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c
> b/CryptoPkg/Library/TlsLib/TlsLib.c
> index ed300c4..e597995 100644
> --- a/CryptoPkg/Library/TlsLib/TlsLib.c
> +++ b/CryptoPkg/Library/TlsLib/TlsLib.c
> @@ -631,6 +631,7 @@ TlsDoHandshake (
> return EFI_INVALID_PARAMETER;
>}
>
> + ret = 1;
>if(BufferIn == NULL && BufferInSize == 0) {
> //
> // If RequestBuffer is NULL and RequestSize is 0, and TLS session
> --
> 1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
Hi Thomas,
One point we should know that TLS cert variable is not defined in UEFI Spec,
it's only private variable used to configure the CA certificate. So, we can't
add this variable check into VarCheckUefiLib. VarCheckUefiLib only contain the
variables defined in UEFI spec, private variable is not allowed.
EDKII_VAR_CHECK_PROTOCOL could be located directly If we truly want to check
one private variable.
In addition, I think defining TlsCaCertificate in GlobalVariable.h is also
unreasonable. This file should only contain globally defined variables with
gEfiGlobalVariableGuid. What do you think?
Moreover, Why put the GUID definition in CryptoPkg.dec? It looks so strange.
Thanks.
Jiaxin
> -Original Message-
> From: Thomas Palmer [mailto:thomas.pal...@hpe.com]
> Sent: Friday, June 24, 2016 2:14 AM
> To: edk2-devel@lists.01.org
> Cc: samer.el-haj-mahm...@hpe.com; Wu, Jiaxin ;
> Zimmer, Vincent ; Li, Ruth ;
> Fu, Siyuan ; Ye, Ting ; Hsiung,
> Harry L ; Thomas Palmer
>
> Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert
> name and guid
>
> Put the TLS cert variable name define into GlobalVariable.h and create a
> GUID for it in CryptoPkg.dec. Describe the minimum size and expected
> variable attributes in VarCheckUefiLib.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Thomas Palmer
> ---
> CryptoPkg/CryptoPkg.dec| 5
> .../Library/VarCheckUefiLib/VarCheckUefiLib.inf| 3 +++
> .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 28
> +-
> MdePkg/Include/Guid/GlobalVariable.h | 7 ++
> NetworkPkg/HttpDxe/HttpDxe.inf | 7 +-
> NetworkPkg/HttpDxe/HttpsSupport.c | 7 +++---
> NetworkPkg/HttpDxe/HttpsSupport.h | 11 +
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf | 3 +++
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c| 11 -
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h| 11 +
> 10 files changed, 61 insertions(+), 32 deletions(-)
>
> diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec index
> ea02ad7..fe04b7d 100644
> --- a/CryptoPkg/CryptoPkg.dec
> +++ b/CryptoPkg/CryptoPkg.dec
> @@ -5,6 +5,7 @@
> # It also provides a test application to test libraries.
> #
> # Copyright (c) 2009 - 2016, 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
> @@ -35,6 +36,10 @@
>##
>TlsLib|Include/Library/TlsLib.h
>
> +[Guids]
> + ## GUID used for TLS Certificate verification
> + gEfiTlsCaCertificateGuid = {0xfd2340D0, 0x3dab, 0x4349, {0xa6, 0xc7,
> +0x3b, 0x4f, 0x12, 0xb4, 0x8e, 0xae}}
> +
> [Protocols]
>## Include/Protocol/RuntimeCrypt.h
>gEfiRuntimeCryptProtocolGuid = { 0xe1475e0c, 0x1746, 0x4802, {0x86, 0x2e,
> 0x1, 0x1c, 0x2c, 0x2d, 0x9d, 0x86 }} diff --git
> a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> index 128c44d..945397a 100644
> --- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> +++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> @@ -36,6 +36,7 @@
> [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> + CryptoPkg/CryptoPkg.dec
>
> [LibraryClasses]
>BaseLib
> @@ -81,6 +82,8 @@
>## SOMETIMES_CONSUMES ## Variable:L"SysPrep"
>## SOMETIMES_CONSUMES ## Variable:L"Key"
>gEfiGlobalVariableGuid
> + ## SOMETIMES_CONSUMES ## Variable:L"TlsCaCertificate"
> + gEfiTlsCaCertificateGuid
>## SOMETIMES_CONSUMES ## Variable:L"DB"
>## SOMETIMES_CONSUMES ## Variable:L"DBX"
>## SOMETIMES_CONSUMES ## Variable:L"DBT"
> diff --git
> a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> index 8f7126e..b820659 100644
> --- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> +++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> @@ -2,6 +2,7 @@
>Implementation functions and structures for var check uefi library.
>
> Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
> +(C) Copyright 2016 Hewlett Packard Enterprise Development LP
> This program and the accompanying materials are licensed and made
> a
Re: [edk2] [Patch] NetworkPkg: Avoid potential NULL pointer dereference
> -Original Message-
> From: Ye, Ting
> Sent: Friday, June 24, 2016 4:25 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Zhang, Lubo
> Subject: RE: [Patch] NetworkPkg: Avoid potential NULL pointer dereference
>
> Looks good to me. I only have one small comment:
>
> + if (EFI_ERROR (Ikev2EncodePacket ((IKEV2_SESSION_COMMON *)
> SessionCommon, IkePacket, IkeType))) {
> +return NULL;
> + }
Ting,
Do you mean any compilers will meet failure or warnings with this one line code?
>
> Do we need divide it into two code lines to satisfy some compilers?
> Status = Ikev2EncodePacket ((IKEV2_SESSION_COMMON *)
> SessionCommon, IkePacket, IkeType)); if (EFI_ERROR (Status)) ...
>
> As long as our supported compilers will not report build errors or warnings, I
> am fine with the update.
>
> Reviewed-by: Ye Ting
>
>
>
> -Original Message-
> From: Wu, Jiaxin
> Sent: Friday, June 24, 2016 3:33 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Zhang,
> Lubo
> Subject: [Patch] NetworkPkg: Avoid potential NULL pointer dereference
>
> The commit of 6b16c9e7 removes ASSERT and use error handling in IpSecDxe
> driver, but may cause the potential NULL pointer dereference. So, this patch
> is used to avoid NULL pointer dereference.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Zhang Lubo
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> NetworkPkg/IpSecDxe/IkePacket.c | 6 +-
> NetworkPkg/IpSecDxe/Ikev2/ChildSa.c | 19 ++--
> NetworkPkg/IpSecDxe/Ikev2/Exchange.c | 10 ++-
> NetworkPkg/IpSecDxe/Ikev2/Payload.c | 3 +
> NetworkPkg/IpSecDxe/Ikev2/Sa.c | 163
> ++-
> 5 files changed, 188 insertions(+), 13 deletions(-)
>
> diff --git a/NetworkPkg/IpSecDxe/IkePacket.c
> b/NetworkPkg/IpSecDxe/IkePacket.c index 8fd395d..d5a938e 100644
> --- a/NetworkPkg/IpSecDxe/IkePacket.c
> +++ b/NetworkPkg/IpSecDxe/IkePacket.c
> @@ -1,9 +1,9 @@
> /** @file
>IKE Packet related operation.
>
> - Copyright (c) 2010, Intel Corporation. All rights reserved.
> + Copyright (c) 2010 - 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.
> @@ -201,11 +201,13 @@ IkeNetbufFromPacket (
> //
> // Convert Host order to Network order for IKE_PACKET header and
> payloads
> // Encryption payloads if needed
> //
> if (((IKEV2_SESSION_COMMON *) SessionCommon)->IkeVer == 2) {
> - Ikev2EncodePacket ((IKEV2_SESSION_COMMON *) SessionCommon,
> IkePacket, IkeType);
> + if (EFI_ERROR (Ikev2EncodePacket ((IKEV2_SESSION_COMMON *)
> SessionCommon, IkePacket, IkeType))) {
> +return NULL;
> + }
> } else {
>//
>//If IKEv1 support, check it here.
>//
>return NULL;
> diff --git a/NetworkPkg/IpSecDxe/Ikev2/ChildSa.c
> b/NetworkPkg/IpSecDxe/Ikev2/ChildSa.c
> index d3859e2..1f0199b 100644
> --- a/NetworkPkg/IpSecDxe/Ikev2/ChildSa.c
> +++ b/NetworkPkg/IpSecDxe/Ikev2/ChildSa.c
> @@ -1,9 +1,9 @@
> /** @file
>The operations for Child SA.
>
> - Copyright (c) 2010, Intel Corporation. All rights reserved.
> + Copyright (c) 2010 - 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.
> @@ -37,22 +37,25 @@ Ikev2CreateChildGenerator (
>IKEV2_CHILD_SA_SESSION *ChildSaSession;
>IKEV2_SA_SESSION*IkeSaSession;
>IKE_PACKET *IkePacket;
>IKE_PAYLOAD *NotifyPayload;
>UINT32 *MessageId;
> +
> + NotifyPayload = NULL;
> + MessageId = NULL;
>
>ChildSaSession = (IKEV2_CHILD_SA_SESSION *) SaSession;
> - IkePacket = IkePacketAlloc();
> - MessageId = NULL;
> -
> - if (IkePacket == NULL) {
> + if (ChildSaSession == NULL) {
> return NULL;
>}
> - if (ChildSaSession == NULL) {
> +
> + IkePacket = IkePacketAlloc();
> + if (IkePacket == NULL) {
> return NULL;
>}
>
> +
>if (Context != NULL) {
> MessageId = (UINT32 *) Context;
>}
>
>IkePacket->
Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
> -Original Message- > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > Sent: Saturday, June 25, 2016 12:51 AM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer ; Zimmer, > Vincent ; Li, Ruth ; Fu, > Siyuan ; Ye, Ting ; Hsiung, Harry L > > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > Jiaxin, et al ~ > > I noticed while using the TLS feature that the GUID and Variable Name define > were being re-defined in multiple spots. Currently, if someone were to write > a UEFI application, there is no single include file that would provide the > variable name in a define. As a matter of sheer better programming practices, > the Variable Name define and GUID should be put into central locations and > not copied all over the codebase. Yes, I agree to put it into a single file. I can create another patch to refine it. If you would like to provide it, I'm fine:). > > With regards to GlobalVariable.h: I realize now this is not the place to put > it. > Because our variable has a unique GUID, we would have to create a new > MdePkg/Include/Guid/ header file to hold the define, much like > ImageAuthentication.h which is also used by VarCheckUefiLibNullClass.c. > > I put the GUID definition into CryptoPkg.dec because the TlsLib and OpenSSL > library are there. I can be persuaded to have it in NetworkPkg.dec as it's > modules are the ultimate consumers of the variable. CryptoPkg is simply > providing libraries. > > With regards to "[TlsCaCertificate is] only a private variable": This > variable is > super critical to secure TLS communication. It is so critical that we are > even > discussing how to protect it in runtime from malicious/careless modifications. > We understand that if this variable were compromised that there could be > severe security implications that follow. This variable must be respected > properly. Actually, I don't have the strong opinion about the security of this variable. TlsCaCertificate is used to store the public certificate that means everyone can get and use it. Take windows OS as an example, any login user can/should have the ability to modify this kind of certificate, we can think it's not protected except for the system-level access control. This is the reason why I put it into plaintext currently. But I also agree that protecting this variable is also meaningful because we no such access control. As for how to protect it, it is another question we discussed before. > > For that reason, I'd argue that we should put the TlsCaCertificate into the > UEFI Spec. When it gets put into the spec I do not know, but we should be > aiming for that. It is too important to security to not be in the spec. In my opinion, TlsCaCertificate variable is just a temporary scenario to hold the certificate, not the finally or general UEFI solution for the certificate management. So, it's pointless to standardize it, keeping it as a private variable is fine currently. > > Not only that, but once this is in the spec it will enable 3rd party > applications > to re-use this variable too. I've personally talked with one such developer > who is eagerly awaiting a variable that is a secure UEFI standard for > Certificate Authority storage. > > Thomas > > -Original Message- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Thursday, June 23, 2016 9:56 PM > To: Palmer, Thomas ; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer ; Zimmer, > Vincent ; Li, Ruth ; Fu, > Siyuan ; Ye, Ting ; Hsiung, Harry L > > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > Hi Thomas, > One point we should know that TLS cert variable is not defined in UEFI Spec, > it's only private variable used to configure the CA certificate. So, we can't > add > this variable check into VarCheckUefiLib. VarCheckUefiLib only contain the > variables defined in UEFI spec, private variable is not allowed. > EDKII_VAR_CHECK_PROTOCOL could be located directly If we truly want to > check one private variable. > > In addition, I think defining TlsCaCertificate in GlobalVariable.h is also > unreasonable. This file should only contain globally defined variables with > gEfiGlobalVariableGuid. What do you think? > > Moreover, Why put the GUID definition in CryptoPkg.dec? It looks so strange. > > Thanks. > Jiaxin > > > > -Original Message- > > From: Thomas Palmer [mailto:thomas.pal...@hpe.com] > > Sent: Friday, June 24, 2016 2:14 AM > > To: edk2-devel@lists.01.org > > Cc: samer.el-haj-mahm...@hpe.com; Wu, Jiaxin ; > > Zimmer, Vi
Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
That's fine. I will create one patch directly:). Thanks. Jiaxin > -Original Message- > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > Sent: Tuesday, June 28, 2016 12:51 AM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: Zimmer, Vincent ; Li, Ruth > ; Fu, Siyuan ; Ye, Ting > ; Hsiung, Harry L ; Shifflett, > Joseph > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > I can create the patch if you tell me where to put everything. Or if you are > like me, may be easier for you to just code it up. Either way is fine > > Thomas > > -Original Message- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Sunday, June 26, 2016 8:38 PM > To: Palmer, Thomas ; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer ; Zimmer, > Vincent ; Li, Ruth ; Fu, > Siyuan ; Ye, Ting ; Hsiung, Harry L > > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > > > > -Original Message- > > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > > Sent: Saturday, June 25, 2016 12:51 AM > > To: Wu, Jiaxin ; edk2-devel@lists.01.org > > Cc: El-Haj-Mahmoud, Samer ; Zimmer, > > Vincent ; Li, Ruth ; Fu, > > Siyuan ; Ye, Ting ; Hsiung, > > Harry L > > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS > > var cert name and guid > > > > Jiaxin, et al ~ > > > > I noticed while using the TLS feature that the GUID and Variable Name > > define were being re-defined in multiple spots. Currently, if someone > > were to write a UEFI application, there is no single include file that > > would provide the variable name in a define. As a matter of sheer > > better programming practices, the Variable Name define and GUID should > > be put into central locations and not copied all over the codebase. > > Yes, I agree to put it into a single file. I can create another patch to > refine it. If > you would like to provide it, I'm fine:). > > > > > With regards to GlobalVariable.h: I realize now this is not the place to > > put it. > > Because our variable has a unique GUID, we would have to create a new > > MdePkg/Include/Guid/ header file to hold the define, much like > > ImageAuthentication.h which is also used by VarCheckUefiLibNullClass.c. > > > > I put the GUID definition into CryptoPkg.dec because the TlsLib and > > OpenSSL library are there. I can be persuaded to have it in > > NetworkPkg.dec as it's modules are the ultimate consumers of the > > variable. CryptoPkg is simply providing libraries. > > > > With regards to "[TlsCaCertificate is] only a private variable": This > > variable > is > > super critical to secure TLS communication. It is so critical that we > > are even discussing how to protect it in runtime from malicious/careless > modifications. > > We understand that if this variable were compromised that there could > > be severe security implications that follow. This variable must be > > respected properly. > > Actually, I don't have the strong opinion about the security of this variable. > TlsCaCertificate is used to store the public certificate that means everyone > can get and use it. Take windows OS as an example, any login user > can/should have the ability to modify this kind of certificate, we can think > it's > not protected except for the system-level access control. This is the reason > why I put it into plaintext currently. But I also agree that protecting this > variable is also meaningful because we no such access control. As for how to > protect it, it is another question we discussed before. > > > > > For that reason, I'd argue that we should put the TlsCaCertificate > > into the UEFI Spec. When it gets put into the spec I do not know, but > > we should be aiming for that. It is too important to security to not be in > > the > spec. > > In my opinion, TlsCaCertificate variable is just a temporary scenario to hold > the certificate, not the finally or general UEFI solution for the certificate > management. So, it's pointless to standardize it, keeping it as a private > variable is fine currently. > > > > > Not only that, but once this is in the spec it will enable 3rd party > > applications to re-use this variable too. I've personally talked with > > one such developer who is eagerly awaiting a variable that is a secure > > UEFI standard for Certificate Authority storage. > > > > Thomas > > > > -Original Message- > > From: Wu,
Re: [edk2] [Patch] NetworkPkg: Stop the HTTP Boot service after the boot image download complete.
Looks good to me! Reviewed-By: Wu Jiaxin Best Regards! Jiaxin > -Original Message- > From: Fu, Siyuan > Sent: Tuesday, June 28, 2016 4:32 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Wu, Jiaxin > Subject: [Patch] NetworkPkg: Stop the HTTP Boot service after the boot > image download complete. > > After boot image has been downloaded, the HTTP boot driver leaves the > service in the started state, with an active TCP child. This may cause some > problems: > 1. The HTTP session may become unavaiable after a while, then a following > HTTP Boot will fail. > 2. An active TCP child will send RST to any incoming TCP message, which may > break other driver which tries to setup a TCP connection. > The HTTP boot driver doesn't provide any interface to the boot loader, so it's > unnecessary to keep the service running after a boot image is downloaded. > > Cc: Ye Ting > Cc: Wu Jiaxin > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Fu Siyuan > --- > NetworkPkg/HttpBootDxe/HttpBootImpl.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/NetworkPkg/HttpBootDxe/HttpBootImpl.c > b/NetworkPkg/HttpBootDxe/HttpBootImpl.c > index 4b850b6..babd3e6 100644 > --- a/NetworkPkg/HttpBootDxe/HttpBootImpl.c > +++ b/NetworkPkg/HttpBootDxe/HttpBootImpl.c > @@ -505,7 +505,11 @@ HttpBootDxeLoadFile ( >Status = EFI_WARN_FILE_SYSTEM; > } >} > - > + > + // > + // Stop the HTTP Boot service after the boot image is downloaded. > + // > + HttpBootStop (Private); >return Status; > } > > -- > 2.7.4.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/6] NetworkPkg: fix ASSERT_EFI_ERROR() typos
Reviewed-By: Wu Jiaxin Best Regards! Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Tuesday, June 28, 2016 9:26 PM > To: edk2-devel-01 > Cc: Fu, Siyuan ; Wu, Jiaxin > Subject: [edk2] [PATCH 2/6] NetworkPkg: fix ASSERT_EFI_ERROR() typos > > A number of code locations use > > ASSERT_EFI_ERROR (BooleanExpression) > > instead of > > ASSERT (BooleanExpression) > > Fix them. > > Cc: Siyuan Fu > Cc: Jiaxin Wu > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- > > Notes: > build tested only > > NetworkPkg/IpSecDxe/Ikev2/Sa.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/NetworkPkg/IpSecDxe/Ikev2/Sa.c > b/NetworkPkg/IpSecDxe/Ikev2/Sa.c index 74ef79c23719..4cbfac33b134 > 100644 > --- a/NetworkPkg/IpSecDxe/Ikev2/Sa.c > +++ b/NetworkPkg/IpSecDxe/Ikev2/Sa.c > @@ -384,7 +384,7 @@ Ikev2InitPskParser ( > // 5. Generate Nr_b > // > IkeSaSession->NrBlock = IkeGenerateNonce (IKE_NONCE_SIZE); > -ASSERT_EFI_ERROR (IkeSaSession->NrBlock != NULL); > +ASSERT (IkeSaSession->NrBlock != NULL); > IkeSaSession->NrBlkSize = IKE_NONCE_SIZE; > > // > -- > 1.8.3.1 > > > ___ > 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] [Patch 0/2] Update-PXE-driver-to-follow-edk2-coding-standards
Series Reviewed-By: Wu Jiaxin Best Regards! Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu > Siyuan > Sent: Thursday, June 30, 2016 10:08 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch 0/2] Update-PXE-driver-to-follow-edk2-coding- > standards > > > Fu Siyuan (2): > MdeModulePkg: Update PXE driver to follow edk2 coding standards. > NetworkPkg: Update PXE driver to follow edk2 coding standards. > > MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c | 4 ++-- > MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.h | 4 ++-- > NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c | 6 +++--- > NetworkPkg/UefiPxeBcDxe/PxeBcSupport.h | 4 ++-- > 4 files changed, 9 insertions(+), 9 deletions(-) > > -- > 2.7.4.windows.1 > > ___ > 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] [patch] ShellPkg: Update the error prompt for ping6 command.
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Zhang Lubo
> Sent: Friday, July 1, 2016 2:13 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin
> Subject: [edk2] [patch] ShellPkg: Update the error prompt for ping6
> command.
>
> when we use the ping6 command without configuring the network interface,
> it should give correct prompt to users.
>
> Cc: Hegde Nagaraj P
> Cc: Fu Siyuan
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo
> ---
> ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c | 2
> +-
> .../UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.uni
> | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> index e4ae977..4496802 100644
> --- a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> +++ b/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> @@ -824,11 +824,11 @@ Ping6CreateIpInstance (
>//
>// No exact interface address matched.
>//
>
>if (HandleIndex == HandleNum) {
> -ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_PING6_SOURCE_NOT_FOUND), gShellNetwork2HiiHandle,
> mIp6SrcString);
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> + (STR_PING6_CONFIGD_NIC_NF), gShellNetwork2HiiHandle);
> Status = EFI_NOT_FOUND;
> goto ON_ERROR;
>}
>
>Private->NicHandle = HandleBuffer[HandleIndex]; diff --git
> a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.uni
> b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.uni
> index fb2bfab..40e0284 100644
> ---
> a/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> mandsLib.uni
> +++
> b/ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Com
> +++ mandsLib.uni
> @@ -29,11 +29,11 @@
> #string STR_PING6_INVALID_BUFFER_SIZE #language en-US "%Ping6:
> Invalid buffer size, %s\r\n"
> #string STR_PING6_INVALID_SOURCE #language en-US "%Ping6:
> Require source interface option\r\n"
> #string STR_PING6_IP6_CONFIG #language en-US "%Ping6: The
> process of Ip6 Configure %r\r\n"
> #string STR_PING6_IP6CFG_GETDATA #language en-US "%Ping6: Get
> data of the interface information %r\r\n"
> #string STR_PING6_SEND_REQUEST #language en-US "Echo request
> sequence %d fails.\r\n"
> -#string STR_PING6_SOURCE_NOT_FOUND #language en-US
> "Source %s not found.\r\n"
> +#string STR_PING6_CONFIGD_NIC_NF #language en-US "%Ping6: No
> configured interfaces were found.\r\n"
> #string STR_PING6_NOSOURCE_INDOMAIN#language en-US "No
> sources in %s's multicast domain.\r\n"
> #string STR_PING6_START#language en-US "Ping %s %d data
> bytes\r\n"
> #string STR_PING6_TIMEOUT #language en-US "Echo request
> sequence %d timeout.\r\n"
> #string STR_PING6_REPLY_INFO #language en-US "%d bytes
> from %s : icmp_seq=%d ttl=%d time%c%dms\r\n"
> #string STR_PING6_STAT #language en-US "\n%d packets
> transmitted, %d received, %d%% packet loss, time %dms\r\n"
> --
> 1.9.5.msysgit.1
>
> ___
> 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] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid
It should be "[edk2-staging/HTTPS-TLS][PATCH]".
Sorry for incorrect subject-prefix.
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, July 5, 2016 9:41 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan
> Subject: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize
> TlsCaCertificate name and guid
>
> This patch is used to centralize TlsCaCertificate name and guid to
> TlsAuthentication.h
>
> Cc: Palmer Thomas
> Cc: Ye Ting
> Cc: Fu Siyuan
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu
> ---
> NetworkPkg/HttpDxe/HttpDriver.h | 2 ++
> NetworkPkg/HttpDxe/HttpDxe.inf | 4
> NetworkPkg/HttpDxe/HttpsSupport.c| 7 ++
> NetworkPkg/HttpDxe/HttpsSupport.h| 10
> NetworkPkg/Include/Guid/TlsAuthentication.h | 29
>
> NetworkPkg/NetworkPkg.dec| 5 +++-
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf | 1 +
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 14 +---
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h | 12 ++
> 9 files changed, 50 insertions(+), 34 deletions(-) create mode 100644
> NetworkPkg/Include/Guid/TlsAuthentication.h
>
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.h
> b/NetworkPkg/HttpDxe/HttpDriver.h index 3c30c12..73c211a 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.h
> +++ b/NetworkPkg/HttpDxe/HttpDriver.h
> @@ -58,10 +58,12 @@
> //
> // Produced Protocols
> //
> #include
>
> +#include
> +
> //
> // Driver Version
> //
> #define HTTP_DRIVER_VERSION 0xa
>
> diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf
> b/NetworkPkg/HttpDxe/HttpDxe.inf index a228c3d..1118181 100644
> --- a/NetworkPkg/HttpDxe/HttpDxe.inf
> +++ b/NetworkPkg/HttpDxe/HttpDxe.inf
> @@ -24,10 +24,11 @@
>MODULE_UNI_FILE = HttpDxe.uni
>
> [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> + NetworkPkg/NetworkPkg.dec
>
> [Sources]
>ComponentName.h
>ComponentName.c
>HttpDns.h
> @@ -69,7 +70,10 @@
>gEfiIp6ConfigProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
>gEfiTlsProtocolGuid ## SOMETIMES_CONSUMES
>gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
>
> +[Guids]
> + gEfiTlsCaCertificateGuid ## CONSUMES ## GUID
> +
> [UserExtensions.TianoCore."ExtraFiles"]
>HttpDxeExtra.uni
> \ No newline at end of file
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c
> b/NetworkPkg/HttpDxe/HttpsSupport.c
> index 09aaa46..36f658c 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.c
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.c
> @@ -12,12 +12,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>
> **/
>
> #include "HttpDriver.h"
>
> -EFI_GUID mEfiTlsCaCertificateGuid = EFI_TLS_CA_CERTIFICATE_GUID;
> -
> /**
>Returns the first occurrence of a Null-terminated ASCII sub-string in a
> Null-
> terminated
>ASCII string and ignore case during the search process.
>
>This function scans the contents of the ASCII string specified by String
> @@ -
> 395,11 +393,11 @@ TlsConfigCertificate (
>// Try to read the TlsCaCertificate variable.
>//
>CACertSize = 0;
>Status = gRT->GetVariable (
> EFI_TLS_CA_CERTIFICATE_VARIABLE,
> - &mEfiTlsCaCertificateGuid,
> + &gEfiTlsCaCertificateGuid,
> NULL,
> &CACertSize,
> NULL
> );
>
> @@ -412,11 +410,11 @@ TlsConfigCertificate (
>return EFI_OUT_OF_RESOURCES;
> }
>
> Status = gRT->GetVariable (
> EFI_TLS_CA_CERTIFICATE_VARIABLE,
> -&mEfiTlsCaCertificateGuid,
> +&gEfiTlsCaCertificateGuid,
> NULL,
> &CACertSize,
> CACert
> );
> if (EFI_ERROR (Status)) {
> @@ -453,11 +451,10 @@ TlsConfigCertificate (
>}
>
>Cert = (EFI_SIGNATURE_DATA *) ((UINT8 *) Cert + CertList-
> >SignatureSize);
> }
>
> -
> ItemDataSize -= CertList->SignatureListSize;
> CertList = (EFI_SIGNATURE_LIST *) ((UINT8 *) CertList + CertList-
> >SignatureListSize);
>}
>
>return Status;
> diff --git a/NetworkPkg/HttpDxe/HttpsSupport.h
> b/NetworkPkg/HttpDxe/HttpsSupport.h
> index 682a6b6..05b6e69 100644
> --- a/NetworkPkg/HttpDxe/HttpsSupport.h
> +++ b/NetworkPkg/HttpDxe/HttpsSupport.h
> @@ -20,20 +20,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> #define HTTPS_DEFAULT_PORT 443
>
> #define HTTPS_FLAG "https"
>
> //
> -// Private variable for CA Certificate c
Re: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hao Wu
> Sent: Tuesday, July 5, 2016 12:59 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ye, Ting ; Fu,
> Siyuan ; Wu, Jiaxin
> Subject: [edk2] [PATCH v2] MdeModulePkg UefiPxeBcDxe: Fix build error for
> lastest VS2015 compiler
>
> The UefiPxeBcDxe module encounters a build error for IA32 arch using the
> latest version of VS2015:
>
> UefiPxe4BcDxe.lib(PxeBcDhcp.obj) : error LNK2001: unresolved external
> symbol __allmul
>
> The cause is line 1659 in file
> MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c. The third
> parameter for gBS->SetTimer() function is of type UINT64, so the
> multiplication should use the MultU64x32() function.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> index 3849613..eac955c 100644
> --- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> +++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcDhcp.c
> @@ -1656,7 +1656,7 @@ PxeBcSelectBootPrompt (
>Status = gBS->SetTimer (
>TimeoutEvent,
>TimerRelative,
> - Timeout * TICKS_PER_SECOND
> + MultU64x32 (Timeout, TICKS_PER_SECOND)
>);
>
>if (EFI_ERROR (Status)) {
> --
> 1.9.5.msysgit.0
>
> ___
> 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] [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Looks it's enough to add the warning debug message. I have sent the version 2
patch to do that.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, February 12, 2019 8:28 AM
> To: Wu, Jiaxin
> Cc: edk2-devel@lists.01.org; Mike Turner ;
> Ye, Ting
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Yes, Jiaxin. You should not use popup messages unless you 100 percent sure
> the code is running in setup browser.
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Mike Turner [mailto:michael.tur...@microsoft.com]
> > Sent: Monday, February 11, 2019 11:10 PM
> > To: Wu, Jiaxin ; Ye, Ting ; edk2-
> > de...@lists.01.org
> > Cc: Fu, Siyuan
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > I haven't seen any patch for a popup, but message popups during driver
> binding
> > start are not a good thing.
> >
> > Michael R Turner
> > Surface UEFI Development
> > Microsoft Corporation
> > One Redmond Way
> > Redmond WA 98052
> >
> > 425-705-0928
> >
> > This email message may contain confidential and privileged
> information. Any
> > unauthorized use is prohibited. If you are not the intended recipient,
> please
> > contact the sender by reply email and destroy all copies of the original
> > message.
> >
> >
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Sunday, February 10, 2019 7:10 PM
> > To: Ye, Ting ; edk2-devel@lists.01.org
> > Cc: Mike Turner ; Fu, Siyuan
> >
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > Agree, thanks the comment. I will update the patch.
> >
> >
> >
> > > -Original Message-
> > > From: Ye, Ting
> > > Sent: Monday, February 11, 2019 11:09 AM
> > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Fu, Siyuan
> > >
> > > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > Hi Jiaxin,
> > >
> > > I agree we need start IPv6 stack no matter the configuration is valid or
> > > not.
> > > However I would suggest to add more comments and pop up warning
> > > messages to let user know we continue to start IPv6 stack without
> > > using previously saved configuration.
> > >
> > > Thanks,
> > > Ting
> > >
> > > -Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Sunday, February 3, 2019 2:24 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Ye, Ting
> > > ; Fu, Siyuan ; Wu, Jiaxin
> > >
> > > Subject: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > REF:
> > >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> > >
> illa.tianocore.org%2Fshow_bug.cgi%3Fid%3D1448&data=02%7C01%7C
> Micha
> > >
> el.Turner%40microsoft.com%7C93fb5d7f003b48c6561d08d68fce66f4%7C72f9
> 88b
> > >
> f86f141af91ab2d7cd011db47%7C1%7C0%7C636854514000398927&sdata
> =bCAbT
> > > njjX9bmuRiASoCkPiZtdqUY14BDMgyLd%2BYNNx4%3D&reserved=0
> > >
> > > This patch is to clean the invalid data and continue to start IP6 driver.
> > >
> > > Cc: Michael Turner
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Wu Jiaxin
> > > Signed-off-by: Michael Turner
> > > ---
> > > NetworkPkg/Ip6Dxe/Ip6Driver.c | 20 ++--
> > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > b/NetworkPkg/Ip6Dxe/Ip6Driver.c index 4c607125a6..1bd1c61da8 100644
> > > --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > @@ -586,11 +586,19 @@ Ip6DriverBindingStart (
> > > Ip6ConfigDataTypeManualAddress,
> > > DataItem->DataSize,
> > > DataItem->Data.Ptr
> > > );
> > > if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> > > - goto UNINSTALL_PROTOCOL;
&
Re: [edk2] [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Hi Siyuan,
Both of them should be fine to clear the invalid configuration data. In my
opinion, since the error returned from SetData(), we will treat it as invalid
except the asynchronous process (EFI_NOT_READY). That's already have been
checked in the if condition.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, February 12, 2019 9:05 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Michael Turner ; Ye, Ting
>
> Subject: RE: [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Hi, Jiaxin
>
> I think the Ip6Cfg->SetData() may return other error, which not only because
> invalid config data is used. Why not just check the config data in
> Ip6ConfigReadConfigData()?
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Tuesday, February 12, 2019 8:47 AM
> > To: edk2-devel@lists.01.org
> > Cc: Michael Turner ; Ye, Ting
> > ; Fu, Siyuan ; Wu, Jiaxin
> >
> > Subject: [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration
> > during driver start.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1448
> >
> > *v2: Add the warning debug message.
> >
> > This patch is to clean the invalid data and continue to start IP6 driver.
> >
> > Cc: Michael Turner
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wu Jiaxin
> > ---
> > NetworkPkg/Ip6Dxe/Ip6Driver.c | 22 --
> > 1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > index 4c607125a6..7ec74f6ebc 100644
> > --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > @@ -586,11 +586,20 @@ Ip6DriverBindingStart (
> > Ip6ConfigDataTypeManualAddress,
> > DataItem->DataSize,
> > DataItem->Data.Ptr
> > );
> > if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> > - goto UNINSTALL_PROTOCOL;
> > + //
> > + // Clean the invalid ManualAddress configuration.
> > + //
> > + Status = Ip6Cfg->SetData (
> > + Ip6Cfg,
> > + Ip6ConfigDataTypeManualAddress,
> > + 0,
> > + NULL
> > + );
> > + DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid
> > ManualAddress configuration.\n"));
> > }
> >}
> >
> >//
> >// If there is any default gateway address, set it.
> > @@ -602,11 +611,20 @@ Ip6DriverBindingStart (
> > Ip6ConfigDataTypeGateway,
> > DataItem->DataSize,
> > DataItem->Data.Ptr
> > );
> > if (EFI_ERROR(Status)) {
> > - goto UNINSTALL_PROTOCOL;
> > + //
> > + // Clean the invalid Gateway configuration.
> > + //
> > + Status = Ip6Cfg->SetData (
> > + Ip6Cfg,
> > + Ip6ConfigDataTypeGateway,
> > + 0,
> > + NULL
> > + );
> > + DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid
> Gateway
> > configuration.\n"));
> > }
> >}
> >
> >//
> >// ready to go: start the receiving and timer
> > --
> > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1] NetworkPkg/DnsDxe: Check the received packet size before parsing the message.
Thanks Laszlo, I will update the subject to include the CVE number when commit the patch. > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Tuesday, February 26, 2019 7:17 PM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Wang, Fan ; Fu, Siyuan > > Subject: Re: [edk2] [PATCH v1] NetworkPkg/DnsDxe: Check the received packet > size before parsing the message. > > On 02/26/19 09:14, Jiaxin Wu wrote: > > Fix CVE-2018-12178 > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=809 > > > > The DNS driver only checks the received packet size against the > > minimum DNS header size in DnsOnPacketReceived(), later it accesses > > the QueryName and QuerySection beyond the header scope, which might > > cause the pointer within DNS driver points to an invalid entry or > > modifies the memory content beyond the header scope. > > > > This patch is to fix above problem. > > > > Cc: Ye Ting > > Cc: Fu Siyuan > > Cc: Wang Fan > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Wu Jiaxin > > --- > > NetworkPkg/DnsDxe/DnsImpl.c | 77 -- > --- > > NetworkPkg/DnsDxe/DnsImpl.h | 2 + > > 2 files changed, 69 insertions(+), 10 deletions(-) > > Please put the precise CVE number in the subject line. > > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
Reviewed-by: Wu Jiaxin
> -Original Message-
> From: Wang, Fan
> Sent: Friday, March 1, 2019 9:57 AM
> To: Fu, Siyuan ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: RE: [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
>
> Thanks, Siyuan, will update commit message for this change.
>
> Best Regards
> Fan
>
> -Original Message-
> From: Fu, Siyuan
> Sent: Thursday, February 28, 2019 6:35 PM
> To: Wang, Fan ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: RE: [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
>
> Hi, Fan
>
> The patch also cancel a timer in driver binding stop, please describe this
> change in commit message, or separate it to another patch.
>
> Reviewed-by: Siyuan Fu
>
> > -Original Message-
> > From: Wang, Fan
> > Sent: Thursday, February 28, 2019 5:10 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ;
> > Wu, Jiaxin
> > Subject: [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
> >
> > * REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1577
> >
> > In WiFi Connection Manager scan process, the result received from WiFi
> > device driver will be freed twice, and will cause unexpected errors,
> > and even system crash.
> >
> > This issue also exists in some other places potentially, this patch is
> > to fix these issues.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Wu Jiaxin
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wang Fan
> > ---
> > NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c| 1
> +
> > NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c | 1
> > + .../WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAccess.c |
> > 9
> > +
> > NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrImpl.c | 1
> -
> > 4 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > index 1431cdc7ea..63b0670c63 100644
> > --- a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > +++
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > @@ -409,10 +409,11 @@ WifiMgrDxeDriverBindingStop (
> >}
> >
> >//
> >// Close Event
> >//
> > + gBS->SetTimer (Nic->TickTimer, TimerCancel, 0);
> >gBS->CloseEvent (Nic->TickTimer);
> >
> >//
> >// Clean Supported Suites
> >//
> > diff --git
> > a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > index 6db1626f2d..0224823431 100644
> > ---
> a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > +++
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > @@ -251,10 +251,11 @@ UpdatePage(
> > }
> >} else {
> >
> > if (Private->FileContext->FileName != NULL) {
> >FreePool (Private->FileContext->FileName);
> > + Private->FileContext->FileName = NULL;
> > }
> > Private->FileContext->FileName = FileName;
> >
> > if (FormId == FORMID_ENROLL_CERT) {
> >HiiSetString (Private->RegisteredHandle, diff --git
> >
> a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAcc
> ess
> > .c
> >
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAcc
> ess
> > .c
> > index bfb6b6e5ca..d0d55f46da 100644
> > ---
> >
> a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAcc
> ess
> > .c
> > +++
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAc
> > +++ cess.c
> > @@ -445,10 +445,12 @@ WifiMgrRefreshNetworkList (
> > UnicodeSPrint (PortString, PortStringSize, L"AKMSuite: %s
> > CipherSuite: %s", AKMListDisplay, CipherListDisplay);
> > PortHelpToken = HiiSetString (Private->RegisteredHandle, 0,
> > PortString, NULL);
> >}
> >FreePool (AKMListDisplay);
> >FreePool (CipherListDisplay);
> > + AKMListDisplay= NULL;
> > + CipherListDisplay = NULL;
> >
> >HiiCreateGotoOpCode (
> > StartOpCodeHandle,
> > FORMID_CONNECT_NETWORK,
> > PortPromptToken,
> > @@ -530,10 +532,12 @@ WifiMgr
[edk2-devel] FW: [staging/UEFI_Redfish][PATCH v2] Announce to create "UEFI_Redfish" branch in edk2-staging.
+ Stephano and forward to new list. Hi All, UEFI_Redfish branch has been created on edk2-staging to develop the UEFI Redfish feature: https://github.com/tianocore/edk2-staging/tree/UEFI_Redfish If you need any support, please send the email to edk2-devel mailing list by following edk2-satging process. Thanks, Jiaxin > -Original Message- > From: Wu, Jiaxin > Sent: Monday, January 21, 2019 2:19 AM > To: edk2-devel@lists.01.org > Cc: Leif Lindholm ; Rothman, Michael A > ; Kinney, Michael D > ; Li, Ruth ; Ye, Ting > ; Fu, Siyuan ; Wang, Fan > ; Wu, Jiaxin > Subject: [staging/UEFI_Redfish][PATCH v2] Announce to create > "UEFI_Redfish" branch in edk2-staging. > > v2: Resend the patch as diff adding instead of modifying. > > UEFI_Redfish branch is to develop the UEFI Redfish feature. The code base > of development is based on the release of edk2-stable201811 tag. Please > refer to the patch of Readme.md to get the detailed feature introduction. > > Note: The branch will be created by the end of Jan 28th if no objection. > > Cc: Leif Lindholm > Cc: Rothman Michael A > Cc: Kinney Michael D > Cc: Li Ruth > Cc: Ye Ting > Cc: Fu Siyuan > Cc: Wang Fan > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Wu Jiaxin > --- > Readme.md | 85 > +++ > 1 file changed, 85 insertions(+) > create mode 100644 Readme.md > > diff --git a/Readme.md b/Readme.md > new file mode 100644 > index 00..b9b5ab38e2 > --- /dev/null > +++ b/Readme.md > @@ -0,0 +1,85 @@ > +This branch is used to develop the **UEFI Redfish Feature**. The code > base of development is based on the release of **edk2-stable201811** tag. > + > +The branch owner: > +Fu Siyuan , Ye Ting , Wang Fan > , Wu Jiaxin > + > +## Introduction > +UEFI Redfish is an efficient and secure solution for end users to remote > control and configure UEFI pre-OS environment by leveraging the RESTful API. > It's simple for end users to access the data from UEFI firmware defined in > JSON format. > + > +One of the design goals for UEFI Redfish solution is to provide a scalable > implementation which allow users to easily add/remove/modify each > independent Redfish configure features (RedfishBiosDxe & > RedfishBootInfoDxe). This is done by extracting the generic logic to a single > UEFI driver model driver (RedfishConfigDxe), and several library instances > (DxeRedfishLib & BaseJsonLib). > + > + Supported Features > + * Protocols > +* EFI RestEx Service Binding Protocol > +* EFI RestEx Protocol > +* Redfish ConfigHandler Protocol > +* Redfish Credential Protocol > + > + * Configuration Items via UEFI Redfish > +* [ISCSI Boot Keywords](http://www.uefi.org/confignamespace). > +* HII Opcodes/Questions marked with REST_SYTLE flag or in REST_SYTLE > formset. > +* BootOrder/BootNext variables. > + > + * Redfish Schemas > +* > [AttributeRegistry](https://redfish.dmtf.org/schemas/v1/AttributeRegistry.v > 1_1_0.json) > +* > [ComputerSystemCollection](https://redfish.dmtf.org/schemas/ComputerS > ystemCollection.json) > +* > [ComputerSystem](https://redfish.dmtf.org/schemas/v1/ComputerSystem. > v1_5_0.json) > +* [Bios](https://redfish.dmtf.org/schemas/v1/Bios.v1_0_2.json) > +* > [BootOptionCollection](https://redfish.dmtf.org/schemas/BootOptionCollec > tion.json) > +* > [BootOption](https://redfish.dmtf.org/schemas/BootOption.v1_0_0.json) > + > +If any additional Redfish Schema or a new version of above Schemas are > required to be supported, please send the email to edk2-devel mailing list by > following [edk2-satging process](https://github.com/tianocore/edk2- > staging). > + > + Related Modules > + The following modules are related to UEFI Redfish solution, > **RedfishPkg** is the new package to support UEFI Redfish solution: > + * **RedfishPkg\RestExDxe\RestExDxe.inf** - UEFI driver to enable > standardized RESTful access to resources from UEFI environment. > + > + * **RedfishPkg\Library\DxeRedfishLib** - Library to > Create/Read/Update/Delete (CRUD) resources and provide basic query > abilities by using [URI/RedPath](https://github.com/DMTF/libredfish). > + > + * **RedfishPkg\Library\BaseJsonLib** - Library to encode/decode JSON > data. > + > + * **RedfishPkg\RedfishConfigDxe\RedfishConfigDxe.inf** - UEFI driver to > execute registered Redfish Configuration Handlers: > + > +* **RedfishPkg\Features\RedfishBiosDxe\RedfishBiosDxe.inf** - DXE > driver to register Redfish configuration handler to process "Bios" schema and > "AttributeRe
Re: [edk2] [PATCH v1] ShellPkg/TftpDynamicCommand: Change file writing method in tftp
Reviewed-by: Wu Jiaxin
Thanks,
Jiaxin
> -Original Message-
> From: Li, Songpeng
> Sent: Wednesday, January 9, 2019 4:42 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ray ;
> Wu, Jiaxin
> Subject: [PATCH v1] ShellPkg/TftpDynamicCommand: Change file writing
> method in tftp
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1433
>
> Current logic of shell tftp download was writing file after tftp
> download finished, when the file is large, it looks like the shell
> tftp command hanged after download was finished. To improve
> end-user experience, the solution is using split file writing
> instead.
>
> This patch update the code to open and close file inside
> DownloadFile(), and save each packet to file within callback
> function CheckPacket().
>
> Since AllocatePage() is no-longer needed, This patch can also
> remove the memory limitation. The download file can be larger
> than system free memory now.
>
> Cc: Jaben Carsey
> Cc: Ruiyu Ni
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Songpeng Li
> ---
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 152
> +---
> 1 file changed, 64 insertions(+), 88 deletions(-)
>
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> index ed081b5bad7c..a53fe16f0683 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> @@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
> // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
> STATIC CONST CHAR16 mTftpProgressDelete[] =
> L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\
> b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
>
> +// Local File Handle
> +SHELL_FILE_HANDLE mFileHandle;
> +
> +// Path of the local file, Unicode encoded
> +CONST CHAR16 *mLocalFilePath;
> +
> /**
>Check and convert the UINT16 option values of the 'tftp' command
>
> @@ -166,9 +172,6 @@ GetFileSize (
>@param[in] FileSize Size of the file in number of bytes
>@param[in] BlockSize Value of the TFTP blksize option
>@param[in] WindowSize Value of the TFTP window size option
> - @param[out] Data Address where to store the address of the
> buffer
> - where the data of the file were downloaded in
> - case of success.
>
>@retval EFI_SUCCESS The file was downloaded.
>@retval EFI_OUT_OF_RESOURCES A memory allocation failed.
> @@ -184,8 +187,7 @@ DownloadFile (
>IN CONST CHAR8 *AsciiFilePath,
>IN UINTNFileSize,
>IN UINT16 BlockSize,
> - IN UINT16 WindowSize,
> - OUT VOID **Data
> + IN UINT16 WindowSize
>);
>
> /**
> @@ -287,7 +289,6 @@ RunTftp (
>CHAR8 *AsciiRemoteFilePath;
>UINTN FilePathSize;
>CONST CHAR16*Walker;
> - CONST CHAR16*LocalFilePath;
>EFI_MTFTP4_CONFIG_DATA Mtftp4ConfigData;
>EFI_HANDLE *Handles;
>UINTN HandleCount;
> @@ -297,9 +298,7 @@ RunTftp (
>EFI_HANDLE Mtftp4ChildHandle;
>EFI_MTFTP4_PROTOCOL *Mtftp4;
>UINTN FileSize;
> - UINTN DataSize;
>VOID*Data;
> - SHELL_FILE_HANDLE FileHandle;
>UINT16 BlockSize;
>UINT16 WindowSize;
>
> @@ -309,7 +308,6 @@ RunTftp (
>AsciiRemoteFilePath = NULL;
>Handles = NULL;
>FileSize= 0;
> - DataSize= 0;
>BlockSize = MTFTP_DEFAULT_BLKSIZE;
>WindowSize = MTFTP_DEFAULT_WINDOWSIZE;
>
> @@ -385,7 +383,7 @@ RunTftp (
>UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
>
>if (ParamCount == 4) {
> -LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
> +mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
>} else {
> Walker = RemoteFilePath + StrLen (RemoteFilePath);
> while ((--Walker) >= RemoteFilePath) {
> @@ -394,7 +392,7 @@ RunTftp (
> break;
>}
> }
> -LocalFilePath = Walker + 1;
> +mLocalFilePath = Walker + 1;
>}
>
>//
> @@ -543,7 +541,7 @@ RunTftp (
>goto NextHandle;
> }
>
> -Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemo
Re: [edk2] [PATCH v2] ShellPkg/TftpDynamicCommand: Change file writing method in tftp
Reviewed-by: Wu Jiaxin
> -Original Message-
> From: Li, Songpeng
> Sent: Thursday, January 10, 2019 10:54 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ray ;
> Wu, Jiaxin
> Subject: [PATCH v2] ShellPkg/TftpDynamicCommand: Change file writing
> method in tftp
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1433
>
> v2: Remove an unused variable.
>
> Current logic of shell tftp download was writing file after tftp
> download finished, when the file is large, it looks like the shell
> tftp command hanged after download was finished. To improve
> end-user experience, the solution is using split file writing
> instead.
>
> This patch update the code to open and close file inside
> DownloadFile(), and save each packet to file within callback
> function CheckPacket().
>
> Since AllocatePage() is no-longer needed, This patch can also
> remove the memory limitation. The download file can be larger
> than system free memory now.
>
> Cc: Jaben Carsey
> Cc: Ruiyu Ni
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Songpeng Li
> ---
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 154 -
> ---
> 1 file changed, 64 insertions(+), 90 deletions(-)
>
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> index ed081b5bad7c..ba753a279b00 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> @@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
> // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
> STATIC CONST CHAR16 mTftpProgressDelete[] =
> L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b
> \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
>
> +// Local File Handle
> +SHELL_FILE_HANDLE mFileHandle;
> +
> +// Path of the local file, Unicode encoded
> +CONST CHAR16 *mLocalFilePath;
> +
> /**
>Check and convert the UINT16 option values of the 'tftp' command
>
> @@ -166,9 +172,6 @@ GetFileSize (
>@param[in] FileSize Size of the file in number of bytes
>@param[in] BlockSize Value of the TFTP blksize option
>@param[in] WindowSize Value of the TFTP window size option
> - @param[out] Data Address where to store the address of the
> buffer
> - where the data of the file were downloaded in
> - case of success.
>
>@retval EFI_SUCCESS The file was downloaded.
>@retval EFI_OUT_OF_RESOURCES A memory allocation failed.
> @@ -184,8 +187,7 @@ DownloadFile (
>IN CONST CHAR8 *AsciiFilePath,
>IN UINTNFileSize,
>IN UINT16 BlockSize,
> - IN UINT16 WindowSize,
> - OUT VOID **Data
> + IN UINT16 WindowSize
>);
>
> /**
> @@ -287,7 +289,6 @@ RunTftp (
>CHAR8 *AsciiRemoteFilePath;
>UINTN FilePathSize;
>CONST CHAR16*Walker;
> - CONST CHAR16*LocalFilePath;
>EFI_MTFTP4_CONFIG_DATA Mtftp4ConfigData;
>EFI_HANDLE *Handles;
>UINTN HandleCount;
> @@ -297,9 +298,6 @@ RunTftp (
>EFI_HANDLE Mtftp4ChildHandle;
>EFI_MTFTP4_PROTOCOL *Mtftp4;
>UINTN FileSize;
> - UINTN DataSize;
> - VOID*Data;
> - SHELL_FILE_HANDLE FileHandle;
>UINT16 BlockSize;
>UINT16 WindowSize;
>
> @@ -309,7 +307,6 @@ RunTftp (
>AsciiRemoteFilePath = NULL;
>Handles = NULL;
>FileSize= 0;
> - DataSize= 0;
>BlockSize = MTFTP_DEFAULT_BLKSIZE;
>WindowSize = MTFTP_DEFAULT_WINDOWSIZE;
>
> @@ -385,7 +382,7 @@ RunTftp (
>UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
>
>if (ParamCount == 4) {
> -LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
> +mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
>} else {
> Walker = RemoteFilePath + StrLen (RemoteFilePath);
> while ((--Walker) >= RemoteFilePath) {
> @@ -394,7 +391,7 @@ RunTftp (
> break;
>}
> }
> -LocalFilePath = Walker + 1;
> +mLocalFilePath = Walker + 1;
>}
>
>//
> @@ -492,7 +489,6 @@ RunTftp (
> (NicNumber < HandleCount) && (ShellStatus != SHELL_SUCCESS);
>
Re: [edk2] [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
Looks good to me.
Reviewed-by: Wu Jiaxin
Thanks,
Jiaxin
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Friday, January 11, 2019 3:27 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin ;
> Ashish Singhal
> Subject: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
>
> Use UEFILib provided protocol uninstallation abstraction
> instead of direct API for a proper cleanup.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1444
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> NetworkPkg/DnsDxe/DnsDriver.c | 30 ++
> NetworkPkg/HttpBootDxe/HttpBootDxe.c | 15 +--
> NetworkPkg/HttpDxe/HttpDriver.c | 15 +--
> NetworkPkg/IpSecDxe/IpSecDriver.c | 15 +--
> NetworkPkg/TcpDxe/TcpDriver.c | 15 +--
> NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 15 +--
> 6 files changed, 35 insertions(+), 70 deletions(-)
>
> diff --git a/NetworkPkg/DnsDxe/DnsDriver.c
> b/NetworkPkg/DnsDxe/DnsDriver.c
> index 1f9b924..b74f5ba 100644
> --- a/NetworkPkg/DnsDxe/DnsDriver.c
> +++ b/NetworkPkg/DnsDxe/DnsDriver.c
> @@ -510,28 +510,18 @@ DnsDriverEntryPoint (
> FreePool (mDriverData);
>
>Error2:
> - gBS->UninstallMultipleProtocolInterfaces (
> - gDns6DriverBinding.DriverBindingHandle,
> - &gEfiDriverBindingProtocolGuid,
> - &gDns6DriverBinding,
> - &gEfiComponentName2ProtocolGuid,
> - &gDnsComponentName2,
> - &gEfiComponentNameProtocolGuid,
> - &gDnsComponentName,
> - NULL
> - );
> + EfiLibUninstallDriverBindingComponentName2 (
> + &gDns6DriverBinding,
> + &gDnsComponentName,
> + &gDnsComponentName2
> + );
>
>Error1:
> -gBS->UninstallMultipleProtocolInterfaces (
> - ImageHandle,
> - &gEfiDriverBindingProtocolGuid,
> - &gDns4DriverBinding,
> - &gEfiComponentName2ProtocolGuid,
> - &gDnsComponentName2,
> - &gEfiComponentNameProtocolGuid,
> - &gDnsComponentName,
> - NULL
> - );
> +EfiLibUninstallDriverBindingComponentName2 (
> + &gDns4DriverBinding,
> + &gDnsComponentName,
> + &gDnsComponentName2
> + );
>
>return Status;
> }
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> index 7ec06f960..0b16f95 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> @@ -1327,16 +1327,11 @@ HttpBootDxeDriverEntryPoint (
> &gHttpBootDxeComponentName2
> );
>if (EFI_ERROR (Status)) {
> -gBS->UninstallMultipleProtocolInterfaces(
> - ImageHandle,
> - &gEfiDriverBindingProtocolGuid,
> - &gHttpBootIp4DxeDriverBinding,
> - &gEfiComponentName2ProtocolGuid,
> - &gHttpBootDxeComponentName2,
> - &gEfiComponentNameProtocolGuid,
> - &gHttpBootDxeComponentName,
> - NULL
> - );
> +EfiLibUninstallDriverBindingComponentName2(
> + &gHttpBootIp4DxeDriverBinding,
> + &gHttpBootDxeComponentName,
> + &gHttpBootDxeComponentName2
> + );
>}
>return Status;
> }
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.c
> b/NetworkPkg/HttpDxe/HttpDriver.c
> index 8df984d..979d76d 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.c
> +++ b/NetworkPkg/HttpDxe/HttpDriver.c
> @@ -230,16 +230,11 @@ HttpDxeDriverEntryPoint (
> &gHttpDxeComponentName2
> );
>if (EFI_ERROR (Status)) {
> -gBS->UninstallMultipleProtocolInterfaces (
> - ImageHandle,
> - &gEfiDriverBindingProtocolGuid,
> - &gHttpDxeIp4DriverBinding,
> - &gEfiComponentName2ProtocolGuid,
> - &gHttpDxeComponentName2,
> - &gEfiComponentNameProtocolGuid,
> - &gHttpDxeComponentName,
> - NULL
> - );
> +EfiLibUninstallDriverBindingComponentName2 (
> + &gHttpDxeIp4DriverBinding,
> + &gHttpDxeComponentName,
> + &gHttpDxeComponentName2
> + );
>}
>return Status;
> }
> diff --git a/NetworkPkg/IpSecDxe/IpSecDriver.c
> b/NetworkPkg/IpSecDxe/IpSecDriver.c
> index f66f89a..3082d99 100644
> --- a/NetworkPkg/IpSecDxe/IpSecDriver.c
> +++ b/Network
Re: [edk2] [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
Already pushed. SHA-1: 22b35e8bd1f9aea7bbab3a26e8ab4df339454463
Thanks,
Jiaxin
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Monday, January 14, 2019 12:58 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan
> Subject: RE: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
>
> Thanks Jiaxin. Please let me know if anything else is needed to mainline it.
>
> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, January 10, 2019 6:01 PM
> To: Ashish Singhal ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan
> Subject: RE: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
>
> Looks good to me.
>
> Reviewed-by: Wu Jiaxin
>
> Thanks,
> Jiaxin
>
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Friday, January 11, 2019 3:27 AM
> > To: edk2-devel@lists.01.org
> > Cc: Fu, Siyuan ; Wu, Jiaxin
> > ; Ashish Singhal
> > Subject: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
> >
> > Use UEFILib provided protocol uninstallation abstraction instead of
> > direct API for a proper cleanup.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1444
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ashish Singhal
> > ---
> > NetworkPkg/DnsDxe/DnsDriver.c | 30 ++
> > NetworkPkg/HttpBootDxe/HttpBootDxe.c | 15 +--
> > NetworkPkg/HttpDxe/HttpDriver.c | 15 +--
> > NetworkPkg/IpSecDxe/IpSecDriver.c | 15 +--
> > NetworkPkg/TcpDxe/TcpDriver.c | 15 +--
> > NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 15 +--
> > 6 files changed, 35 insertions(+), 70 deletions(-)
> >
> > diff --git a/NetworkPkg/DnsDxe/DnsDriver.c
> > b/NetworkPkg/DnsDxe/DnsDriver.c index 1f9b924..b74f5ba 100644
> > --- a/NetworkPkg/DnsDxe/DnsDriver.c
> > +++ b/NetworkPkg/DnsDxe/DnsDriver.c
> > @@ -510,28 +510,18 @@ DnsDriverEntryPoint (
> > FreePool (mDriverData);
> >
> >Error2:
> > - gBS->UninstallMultipleProtocolInterfaces (
> > - gDns6DriverBinding.DriverBindingHandle,
> > - &gEfiDriverBindingProtocolGuid,
> > - &gDns6DriverBinding,
> > - &gEfiComponentName2ProtocolGuid,
> > - &gDnsComponentName2,
> > - &gEfiComponentNameProtocolGuid,
> > - &gDnsComponentName,
> > - NULL
> > - );
> > + EfiLibUninstallDriverBindingComponentName2 (
> > + &gDns6DriverBinding,
> > + &gDnsComponentName,
> > + &gDnsComponentName2
> > + );
> >
> >Error1:
> > -gBS->UninstallMultipleProtocolInterfaces (
> > - ImageHandle,
> > - &gEfiDriverBindingProtocolGuid,
> > - &gDns4DriverBinding,
> > - &gEfiComponentName2ProtocolGuid,
> > - &gDnsComponentName2,
> > - &gEfiComponentNameProtocolGuid,
> > - &gDnsComponentName,
> > - NULL
> > - );
> > +EfiLibUninstallDriverBindingComponentName2 (
> > + &gDns4DriverBinding,
> > + &gDnsComponentName,
> > + &gDnsComponentName2
> > + );
> >
> >return Status;
> > }
> > diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > index 7ec06f960..0b16f95 100644
> > --- a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > +++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > @@ -1327,16 +1327,11 @@ HttpBootDxeDriverEntryPoint (
> > &gHttpBootDxeComponentName2
> > );
> >if (EFI_ERROR (Status)) {
> > -gBS->UninstallMultipleProtocolInterfaces(
> > - ImageHandle,
> > - &gEfiDriverBindingProtocolGuid,
> > - &gHttpBootIp4DxeDriverBinding,
> > - &gEfiComponentName2ProtocolGuid,
> > - &gHttpBootDxeComponentName2,
> > - &gEfiComponentNameProtocolGuid,
> > - &gHttpBootDxeComponentName,
> > - NULL
> > - );
> > +EfiLibUninstallDriverBindingComponentName2(
> > + &gHttpBootIp4DxeDriverBinding,
> > + &gHttpBootDxeComponentName,
> > + &gHttpBootDxeComponentName2
> > + );
> >}
> &
Re: [edk2] [PATCH v1 0/2] Remove unused global variables in
Series Reviewed-by: Jiaxin Wu Thanks, jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Songpeng Li > Sent: Monday, January 14, 2019 5:25 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v1 0/2] Remove unused global variables in > > Uefi-aware compiler found some redundant definitions in > the NetworkPkg. We need to clean them. > > Songpeng Li (2): > NetworkPkg/IScsiDxe: Remove unused global variables. > NetworkPkg/Dhcp6Dxe: Remove an unused global variable. > > NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c | 2 -- > NetworkPkg/IScsiDxe/IScsiConfig.c | 2 -- > NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h | 1 - > 3 files changed, 5 deletions(-) > > -- > 2.18.0.windows.1 > > ___ > 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] [PATCH v1 1/2] MdeModulePkg/NetLib.h: Fix the possible NULL pointer dereference issue.
Hi Laszlo, Thanks review the patch. > > (1) The linked list from BaseLib (LIST_ENTRY) always has at least one > element (the head element), and the list is empty if the head element > points back to itself. In other words, ForwardLink may never be NULL. > > So why is it necessary to check against that case here? > I agree the ForwardLink in valid LIST_ENTRY can't be NULL. Here, I added the more condition check was considering the possible broken case of the LIST_ENTRY. But I also checked the other usage of *_FOR_EACH_SAFE /*_FOR_EACH, looks never or unnecessary to consider that case. If so, please drop the series patches and I will create another series patches to remove the unnecessary check after retrieving the value from list Entry. > (2) If the NULL check is indeed necessary for some reason, then we > should write > > Entry != (ListHead) && Entry != NULL > > in the controlling expression. Because, with the comma operator, the > (Entry != (ListHead)) expression would be evaluated, but its result > would be ignored. > Yes, I was also awared that, so I created patch v2 to fix that: [edk2] [PATCH v2 1/2] MdeModulePkg/NetLib.h: Fix the possible NULL pointer dereference issue. Fix the wrong condition in for cycle. Thanks, Jiaxin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
Thanks Siyuan, I will double check that.
> -Original Message-
> From: Fu, Siyuan
> Sent: Friday, January 18, 2019 10:00 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Hao A ; Gao,
> Liming
> Subject: RE: [PATCH v1 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary NULL pointer check.
>
> Hi, Jiaxin
>
> > -----Original Message-
> > From: Wu, Jiaxin
> > Sent: Thursday, January 17, 2019 9:01 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Hao A
> > ; Gao, Liming ; Wu, Jiaxin
> >
> > Subject: [PATCH v1 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary
> NULL pointer
> > check.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469
> >
> > Since the value of Instance is retrieved from the list Entry,
> > it can't be the NULL pointer, so just remove the unnecessary
> > check.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Wu Hao A
> > Cc: Gao Liming
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wu Jiaxin
> > ---
> > MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 15 ++
> -
> > 1 file changed, 6 insertions(+), 9 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > index 98a22a77b4..04d47e0759 100644
> > --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > @@ -1,9 +1,9 @@
> > /** @file
> >EFI DHCP protocol implementation.
> >
> > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > +Copyright (c) 2006 - 2019, 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
> >
> > @@ -1493,15 +1493,15 @@ DhcpOnTimerTick (
> >IN EFI_EVENT Event,
> >IN VOID *Context
> >)
> > {
> >LIST_ENTRY*Entry;
> > - LIST_ENTRY*Next;
> >DHCP_SERVICE *DhcpSb;
> >DHCP_PROTOCOL *Instance;
> >EFI_STATUSStatus;
> >
> > + Entry= NULL;
> >DhcpSb = (DHCP_SERVICE *) Context;
> >Instance = DhcpSb->ActiveChild;
> >
> >//
> >// 0x is the maximum supported value for elapsed time according to
> RFC.
> > @@ -1644,18 +1644,15 @@ DhcpOnTimerTick (
> >
> > ON_EXIT:
> >//
> >// Iterate through all the DhcpSb Children.
> >//
> > - NET_LIST_FOR_EACH_SAFE (Entry, Next, &DhcpSb->Children) {
> > + NET_LIST_FOR_EACH (Entry, &DhcpSb->Children) {
>
> The DHCP Instance might be destroyed in PxeDhcpDone (it singals upper
> layer that the DHCP is completed), and the NET_LIST_FOR_EACH is not
> delete-safe, you should not replace it with NET_LIST_FOR_EACH.
>
> > Instance = NET_LIST_USER_STRUCT (Entry, DHCP_PROTOCOL, Link);
> > -
> > -if ((Instance != NULL) && (Instance->Token != NULL)) {
> > - Instance->Timeout--;
> > - if (Instance->Timeout == 0) {
> > -PxeDhcpDone (Instance);
> > - }
> > +Instance->Timeout--;
> > +if (Instance->Timeout == 0) {
> > + PxeDhcpDone (Instance);
> > }
> >}
> >
> >return ;
> >
> > --
> > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
Just confirmed with Liming, we don't need to seed the full series patches if
only one is updated.
Thanks,
jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Friday, January 18, 2019 1:29 PM
> To: Wu, Hao A ; Wu, Jiaxin ;
> edk2-devel@lists.01.org
> Cc: Ye, Ting ; Gao, Liming
> Subject: RE: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary NULL pointer check.
>
> Hi, Jiaxin
>
> Yes the full patch series is needed for a v2 version.
>
> And also, why you removed the "(Instance->Token != NULL)" check in the if
> condition?
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-----
> > From: Wu, Hao A
> > Sent: Friday, January 18, 2019 1:22 PM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ; Gao,
> > Liming
> > Subject: RE: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary NULL
> > pointer check.
> >
> > Hi Jiaxin,
> >
> > A comment that is not related with the content of the patch itself:
> > Please help to send the full patch series when a new version is needed.
> >
> > Best Regards,
> > Hao Wu
> >
> > > -----Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Friday, January 18, 2019 1:16 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Ye, Ting; Fu, Siyuan; Wu, Hao A; Gao, Liming; Wu, Jiaxin
> > > Subject: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary
> > > NULL pointer check.
> > >
> > > v2: The DHCP Instance might be destroyed in PxeDhcpDone. So,
> > > we need safe-delete.
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469
> > >
> > > Since the value of Instance is retrieved from the list Entry,
> > > it can't be the NULL pointer, so just remove the unnecessary
> > > check.
> > >
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Cc: Wu Hao A
> > > Cc: Gao Liming
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Wu Jiaxin
> > > ---
> > > MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 11 -
> --
> > > 1 file changed, 4 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > index 98a22a77b4..780f8b4224 100644
> > > --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > @@ -1,9 +1,9 @@
> > > /** @file
> > >EFI DHCP protocol implementation.
> > >
> > > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > > +Copyright (c) 2006 - 2019, 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
> > >
> > > @@ -1646,16 +1646,13 @@ ON_EXIT:
> > >//
> > >// Iterate through all the DhcpSb Children.
> > >//
> > >NET_LIST_FOR_EACH_SAFE (Entry, Next, &DhcpSb->Children) {
> > > Instance = NET_LIST_USER_STRUCT (Entry, DHCP_PROTOCOL, Link);
> > > -
> > > -if ((Instance != NULL) && (Instance->Token != NULL)) {
> > > - Instance->Timeout--;
> > > - if (Instance->Timeout == 0) {
> > > -PxeDhcpDone (Instance);
> > > - }
> > > +Instance->Timeout--;
> > > +if (Instance->Timeout == 0) {
> > > + PxeDhcpDone (Instance);
> > > }
> > >}
> > >
> > >return ;
> > >
> > > --
> > > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [staging/UEFI_Redfish][PATCH v1] Announce to create "UEFI_Redfish" branch in edk2-staging.
Good suggestion. Thanks Leif. Already resubmit as version 2. > -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Friday, January 18, 2019 9:19 PM > To: Wu, Jiaxin > Cc: edk2-devel@lists.01.org; Wang, Fan ; Ye, Ting > ; Li, Ruth ; Kinney, Michael D > ; Fu, Siyuan > Subject: Re: [edk2] [staging/UEFI_Redfish][PATCH v1] Announce to create > "UEFI_Redfish" branch in edk2-staging. > > Hi Jiaxin, > > I am happy to see the creation of this branch. However, Could you > possibly resubmit this as a diff adding a Readme.md rather than > modifying it? > > The diff against edk2/Readme.md is not really relevant, and confuses review. > > (For example, in your branch, *delete* the existing Readme.md in a > separate commit, and then in the commit next *add* the one for the > branch. Only the *add* patch needs to be reviewed.) > > Best Regards, > > Leif > > On Fri, Jan 18, 2019 at 05:42:40PM +0800, Jiaxin Wu wrote: > > UEFI_Redfish branch is to develop the UEFI Redfish feature. The code base > > of development is based on the release of edk2-stable201811 tag. Please > > refer to the patch of Readme.md to get the detailed feature introduction. > > > > Note: The branch will be created by the end of Jan 28th if no objection. > > > > Cc: Rothman Michael A > > Cc: Kinney Michael D > > Cc: Li Ruth > > Cc: Ye Ting > > Cc: Fu Siyuan > > Cc: Wang Fan > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Wu Jiaxin > > --- > > Readme.md | 114 > -- > > 1 file changed, 85 insertions(+), 29 deletions(-) > > > > diff --git a/Readme.md b/Readme.md > > index 1ef0780ee0..b9b5ab38e2 100644 > > --- a/Readme.md > > +++ b/Readme.md > > @@ -1,29 +1,85 @@ > > -# EDK II Project > > - > > -A modern, feature-rich, cross-platform firmware development environment > > -for the UEFI and PI specifications from www.uefi.org. > > - > > -Contributions to the EDK II open source project are covered by the > > -[TianoCore Contribution Agreement 1.1](Contributions.txt) > > - > > -The majority of the content in the EDK II open source project uses a > > -[BSD 2-Clause License](License.txt). The EDK II open source project > > contains > > -the following components that are covered by additional licenses: > > -* [AppPkg/Applications/Python/Python- > 2.7.2/Tools/pybench](AppPkg/Applications/Python/Python- > 2.7.2/Tools/pybench/LICENSE) > > -* [AppPkg/Applications/Python/Python- > 2.7.2](AppPkg/Applications/Python/Python-2.7.2/LICENSE) > > -* [AppPkg/Applications/Python/Python- > 2.7.10](AppPkg/Applications/Python/Python-2.7.10/LICENSE) > > -* > [BaseTools/Source/C/BrotliCompress](BaseTools/Source/C/BrotliCompress/LIC > ENSE) > > -* > [MdeModulePkg/Library/BrotliCustomDecompressLib](MdeModulePkg/Library/ > BrotliCustomDecompressLib/LICENSE) > > -* [OvmfPkg](OvmfPkg/License.txt) > > -* > [CryptoPkg/Library/OpensslLib/openssl](CryptoPkg/Library/OpensslLib/openssl/ > LICENSE) > > - > > -The EDK II Project is composed of packages. The maintainers for each > package > > -are listed in [Maintainers.txt](Maintainers.txt). > > - > > -# Resources > > -* [TianoCore](http://www.tianocore.org) > > -* [EDK II](https://github.com/tianocore/tianocore.github.io/wiki/EDK-II) > > -* [Getting Started with EDK > II](https://github.com/tianocore/tianocore.github.io/wiki/Getting-Started-with- > EDK-II) > > -* [Mailing > Lists](https://github.com/tianocore/tianocore.github.io/wiki/Mailing-Lists) > > -* [TianoCore Bugzilla](https://bugzilla.tianocore.org) > > -* [How To > Contribute](https://github.com/tianocore/tianocore.github.io/wiki/How-To- > Contribute) > > +This branch is used to develop the **UEFI Redfish Feature**. The code base > of development is based on the release of **edk2-stable201811** tag. > > + > > +The branch owner: > > +Fu Siyuan , Ye Ting , Wang Fan > , Wu Jiaxin > > + > > +## Introduction > > +UEFI Redfish is an efficient and secure solution for end users to remote > control and configure UEFI pre-OS environment by leveraging the RESTful API. > It's simple for end users to access the data from UEFI firmware defined in > JSON > format. > > + > > +One of the design goals for UEFI Redfish solution is to provide a scalable > implementation which allow users to easily add/remove/modify each > independent Redfish configure features (RedfishBiosDxe & RedfishBootInfoDxe). > This is done
Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
> >> This is my idea to avoid the duplicated mail. I also include Ard and > >> Laszlo to > collect the feedback on how to handle the partial update in the patchset. > >> > > > > Laszlo may disagree with me, but I think that it is not always > > necessary to resend the entire series when only a single patch > > changes. It does depend on the situation, though: if it is a trivial > > patch in a more complicated series then it might make little sense. In > > other case, just resending the whole thing is probably better. > > I think resending one patch can be acceptable, but the subject line > (patch nr) and the threading have to be correct. Also, I don't think > this approach scales beyond exactly one patch-update; it's easy to lose > track of version numbers etc. So "use sparingly" I guess? :) > Thanks all of your comments, to avoid the missing version track, I have resent the whole patch to version 3:). Best Regard! Jiaxin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Network Stack Budgeting
Hi Tom, One thing I want to highlight is that our design of network stack is not only for the PXE/HTTP boot trigged in BootManager, but also to make sure it's workable once there is any MNP instance configured by upper drivers (ARP/IPv4/IPv6). Take ARP/IP as an example, once ARP/IP are started, we need a heartbeat to process any ARP requests, which is required by ARP functionality. In such a case, SNP must be started to make ARP/IP drivers works well. Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tomas Pilar (tpilar) > Sent: Friday, January 25, 2019 1:43 AM > To: Laszlo Ersek ; edk2-devel@lists.01.org > Subject: Re: [edk2] Network Stack Budgeting > > > > On 24/01/2019 16:49, Laszlo Ersek wrote: > > On 01/24/19 14:25, Tomas Pilar (tpilar) wrote: > >> Hmm, > >> > >> Mnp->Configure() will eventually call MnpStartSnp(). > >> > >> A grep for Mnp->Configure shows that: > >> * ArpDxe performs this on DriverBinding.Start() > >> * Ip6Dxe performs this on DriverBinding.Start() > >> > >> Ipv4 and DnsDhcp do this as a part of their Configure() they expose in the > API. > > Yes, that makes sense. All of the above drivers are UEFI drivers that > > follow the UEFI driver model, AIUI. As long as the controller is not > > connected from BDS, no BindingStart() function should be called in these. > Ah, but I would expect the BDS to call ConnectController() on the NIC, but I > would not expect the network stack to be started unless the device is > actually chosen for PXE booting. In other words, the above protocols should > follow the example of EFI_DNS4_PROTOCOL that binds against the device > during BDS but .Configure() is not automatically called by > DriverBinding.Start(). > > .Configure() should be called by the BootManager if networking is actually to > be done. That in turn will configure Mnp and start Snp. > > Cheers, > Tom > > ___ > 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] [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Agree, thanks the comment. I will update the patch.
> -Original Message-
> From: Ye, Ting
> Sent: Monday, February 11, 2019 11:09 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Michael Turner ; Fu, Siyuan
>
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Hi Jiaxin,
>
> I agree we need start IPv6 stack no matter the configuration is valid or not.
> However I would suggest to add more comments and pop up warning
> messages to let user know we continue to start IPv6 stack without using
> previously saved configuration.
>
> Thanks,
> Ting
>
> -Original Message-
> From: Wu, Jiaxin
> Sent: Sunday, February 3, 2019 2:24 PM
> To: edk2-devel@lists.01.org
> Cc: Michael Turner ; Ye, Ting
> ; Fu, Siyuan ; Wu, Jiaxin
>
> Subject: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration
> during driver start.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1448
>
> This patch is to clean the invalid data and continue to start IP6 driver.
>
> Cc: Michael Turner
> Cc: Ye Ting
> Cc: Fu Siyuan
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin
> Signed-off-by: Michael Turner
> ---
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> b/NetworkPkg/Ip6Dxe/Ip6Driver.c index 4c607125a6..1bd1c61da8 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> @@ -586,11 +586,19 @@ Ip6DriverBindingStart (
> Ip6ConfigDataTypeManualAddress,
> DataItem->DataSize,
> DataItem->Data.Ptr
> );
> if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> - goto UNINSTALL_PROTOCOL;
> + //
> + // Clean the invalid ManualAddress configuration.
> + //
> + Status = Ip6Cfg->SetData (
> + Ip6Cfg,
> + Ip6ConfigDataTypeManualAddress,
> + 0,
> + NULL
> + );
> }
>}
>
>//
>// If there is any default gateway address, set it.
> @@ -602,11 +610,19 @@ Ip6DriverBindingStart (
> Ip6ConfigDataTypeGateway,
> DataItem->DataSize,
> DataItem->Data.Ptr
> );
> if (EFI_ERROR(Status)) {
> - goto UNINSTALL_PROTOCOL;
> + //
> + // Clean the invalid Gateway configuration.
> + //
> + Status = Ip6Cfg->SetData (
> + Ip6Cfg,
> + Ip6ConfigDataTypeGateway,
> + 0,
> + NULL
> + );
> }
>}
>
>//
>// ready to go: start the receiving and timer
> --
> 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 13/16] NetworkPkg: Series of patches to fix typos
Reviewed-By: Wu Jiaxin Best Regards! Jiaxin > -Original Message- > From: Mudusuru, Giri P > Sent: Thursday, July 7, 2016 3:48 PM > To: edk2-devel@lists.01.org > Cc: Fu, Siyuan ; Wu, Jiaxin > Subject: [edk2] [PATCH 13/16] NetworkPkg: Series of patches to fix typos > > - abstrated to abstracted > - apropriate to appropriate > - availabe to available > - ptototypes to prototypes > - prococol protocol > > Cc: Siyuan Fu > Cc: Jiaxin Wu > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Giri P Mudusuru > --- > NetworkPkg/Dhcp6Dxe/Dhcp6Driver.h | 2 +- > NetworkPkg/DnsDxe/DnsDriver.c | 4 ++-- > NetworkPkg/DnsDxe/DnsDriver.h | 4 ++-- > NetworkPkg/HttpDxe/HttpDriver.c | 2 +- > NetworkPkg/HttpDxe/HttpDriver.h | 2 +- > NetworkPkg/Ip6Dxe/Ip6Driver.c | 2 +- > NetworkPkg/Ip6Dxe/Ip6Driver.h | 4 ++-- > NetworkPkg/TcpDxe/TcpDriver.c | 2 +- > NetworkPkg/TcpDxe/TcpDriver.h | 2 +- > NetworkPkg/Udp6Dxe/Udp6Driver.c | 2 +- > NetworkPkg/Udp6Dxe/Udp6Driver.h | 2 +- > NetworkPkg/Udp6Dxe/Udp6Impl.c | 6 +++--- > 12 files changed, 17 insertions(+), 17 deletions(-) > > diff --git a/NetworkPkg/Dhcp6Dxe/Dhcp6Driver.h > b/NetworkPkg/Dhcp6Dxe/Dhcp6Driver.h > index bec47a0..0c0140c 100644 > --- a/NetworkPkg/Dhcp6Dxe/Dhcp6Driver.h > +++ b/NetworkPkg/Dhcp6Dxe/Dhcp6Driver.h > @@ -116,7 +116,7 @@ Dhcp6DriverBindingStop ( > >@retval EFI_SUCCESThe protocol was added to ChildHandle. >@retval EFI_INVALID_PARAMETER ChildHandle is NULL. > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > availabe to create > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > + available to create > the child. >@retval other The child handle was not created. > > diff --git a/NetworkPkg/DnsDxe/DnsDriver.c > b/NetworkPkg/DnsDxe/DnsDriver.c index 6ca8aa7..85589fb 100644 > --- a/NetworkPkg/DnsDxe/DnsDriver.c > +++ b/NetworkPkg/DnsDxe/DnsDriver.c > @@ -1081,7 +1081,7 @@ Dns6DriverBindingStop ( > >@retval EFI_SUCCESThe protocol was added to ChildHandle. >@retval EFI_INVALID_PARAMETER ChildHandle is NULL. > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > availabe to create > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > + available to create > the child >@retval other The child handle was not created > > @@ -1324,7 +1324,7 @@ Dns4ServiceBindingDestroyChild ( > >@retval EFI_SUCCESThe protocol was added to ChildHandle. >@retval EFI_INVALID_PARAMETER ChildHandle is NULL. > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > availabe to create > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > + available to create > the child >@retval other The child handle was not created > > diff --git a/NetworkPkg/DnsDxe/DnsDriver.h > b/NetworkPkg/DnsDxe/DnsDriver.h index f6b8a7e..0339d28 100644 > --- a/NetworkPkg/DnsDxe/DnsDriver.h > +++ b/NetworkPkg/DnsDxe/DnsDriver.h > @@ -514,7 +514,7 @@ Dns6DriverBindingStop ( > >@retval EFI_SUCCESThe protocol was added to ChildHandle. >@retval EFI_INVALID_PARAMETER ChildHandle is NULL. > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > availabe to create > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > + available to create > the child >@retval other The child handle was not created > > @@ -565,7 +565,7 @@ Dns4ServiceBindingDestroyChild ( > >@retval EFI_SUCCESThe protocol was added to ChildHandle. >@retval EFI_INVALID_PARAMETER ChildHandle is NULL. > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > availabe to create > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > + available to create > the child >@retval other The child handle was not created > > diff --git a/NetworkPkg/HttpDxe/HttpDriver.c > b/NetworkPkg/HttpDxe/HttpDriver.c index 0bde012..4d6b1c7 100644 > --- a/NetworkPkg/HttpDxe/HttpDriver.c > +++ b/NetworkPkg/HttpDxe/HttpDriver.c > @@ -911,7 +911,7 @@ HttpDxeIp6DriverBindingStop ( > >@retval EFI_SUCCESThe protocol was added to ChildHandle. >@retval EFI_INVALID_PARAMETER This is NULL, or ChildHandle is NULL. > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > availabe to create > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > + availa
Re: [edk2] [patch] NetworkPkg: Fix Assert issue in iSCSI driver.
Reviewed-By: Wu Jiaxin
Best Regards!
Jiaxin
> -Original Message-
> From: Zhang, Lubo
> Sent: Friday, July 8, 2016 3:51 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Ye, Ting ; Wu,
> Jiaxin
> Subject: [patch] NetworkPkg: Fix Assert issue in iSCSI driver.
>
> The bug existed in replacing AsciiStrToUnicodeStr with AsciiStrToUnicodeStrS,
> since MacString now is a pointer, the value sizeof(MacString)/sizeof
> (MacString[0]) is not correct here as the third parameter.
>
> Cc: Fu Siyuan
> Cc: Ye Ting
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Zhang Lubo
> ---
> NetworkPkg/IScsiDxe/IScsiConfig.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c
> b/NetworkPkg/IScsiDxe/IScsiConfig.c
> index 8015e3d..3631e72 100644
> --- a/NetworkPkg/IScsiDxe/IScsiConfig.c
> +++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
> @@ -685,11 +685,11 @@ IScsiConvertIfrNvDataToAttemptConfigData (
>MacString = (CHAR16 *) AllocateZeroPool (ISCSI_MAX_MAC_STRING_LEN *
> sizeof (CHAR16));
>if (MacString == NULL) {
> return EFI_OUT_OF_RESOURCES;
>}
>
> - AsciiStrToUnicodeStrS (Attempt->MacString, MacString, sizeof (MacString)
> / sizeof (MacString[0]));
> + AsciiStrToUnicodeStrS (Attempt->MacString, MacString,
> + ISCSI_MAX_MAC_STRING_LEN);
>
>UnicodeSPrint (
> mPrivate->PortString,
> (UINTN) ISCSI_NAME_IFR_MAX_SIZE,
> L"MAC: %s, PFA: Bus %d | Dev %d | Func %d, iSCSI mode: %s, IP
> version: %s",
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Fix potential assert issue and coding style refine
I'd like to separate the patches covered in the original one(Live Certificate support) to fix the potential assert issue and refine the coding style first. Please help to review. Thanks. Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jiaxin Wu > Sent: Monday, July 11, 2016 1:43 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ; Long, > Qin > Subject: [edk2] [staging/HTTPS-TLS][PATCH 0/2] Fix potential assert issue and > coding style refine > > Cc: Palmer Thomas > Cc: Samer El-Haj-Mahmoud > Cc: Long Qin > Cc: Ye Ting > Cc: Fu Siyuan > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jiaxin Wu > > Jiaxin Wu (2): > CryptoPkg/Library/TlsLib: Refine the coding style > NetworkPkg: Fix potential assert issue > > CryptoPkg/Library/TlsLib/TlsLib.c | 52 +++--- > - > NetworkPkg/HttpDxe/HttpsSupport.c | 16 > 2 files changed, 42 insertions(+), 26 deletions(-) > > -- > 1.9.5.msysgit.1 > > ___ > 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
