From: "Cohen, Eugene" <eugene@hp.com>
To: "Wu, Jiaxin" <jiaxin.wu@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: IP4 Config Troubles with DHCP
Date: Fri, 12 Aug 2016 12:34:30 +0000 [thread overview]
Message-ID: <AT5PR84MB0291D48234E2107AE8A16886B41F0@AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <895558F6EA4E3B41AC93A00D163B7274137C65C5@SHSMSX103.ccr.corp.intel.com>
> Eugene,
>
> I can reproduce the issue now. And root cause as below:
>
> #1. Set policy to DHCP.
> #2. If DHCP process is not complete yet, then run one App to invoke the
> UDP4 Configure with "UseDefaultAddress = TRUE" (loop to keep calling
> Udp4->Configure until Ip4Mode.IsConfigured changes to TRUE)
> #3. Even DHCP succeed but Ip4Mode.IsConfigured flag never set to TRUE --
> -- failure here!!!
>
> In step1, the policy will be set to DHCP, and then
> Ip4Config2OnPolicyChanged() will be called. In this function, "IpSb-
> >Reconfig" flag will be set to TRUE before Ip4StartAutoConfig() called. That
> means the original "IpSb->DefaultInterface" will be abandoned/freed once
> this DHCP process finished. Detailed see Ip4Config2SetDefaultAddr()
> function.
>
> In step2, UDP4 Configure with "UseDefaultAddress = TRUE" is called, that
> means the default interface (IpSb->DefaultInterface) will be selected as
> current instance's interface. Detailed see Ip4ConfigProtocol() function.
>
> In step3, When DHCP process finished, as I said in step1, the original "IpSb-
> >DefaultInterface" will be abandoned/freed because "IpSb->Reconfig" flag is
> true. Meanwhile, one new interface is assigned to "IpSb->DefaultInterface".
> This "IpSb->DefaultInterface" is different to the original one assigned to the
> UDP4 Configured instance. So, even DHCP process succeed, the up caller will
> never have the chance to get it's truly status.
>
> I will send one patch to fix this issue later.
>
> Thanks your reporting.
>
> Best Regards!
> Jiaxin
Jiaxin, excellent to hear. I'm glad to hear you've isolated the issue. So the service binding instance we have in this case is orphaned which explains why destroying it and creating a new one resolves the issue. Of course we'd be happy to test the patch as soon as it's available.
Thank you!
Eugene
next prev parent reply other threads:[~2016-08-12 12:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-10 18:13 IP4 Config Troubles with DHCP Cohen, Eugene
2016-08-11 6:57 ` FW: " Wu, Jiaxin
2016-08-11 14:31 ` Cohen, Eugene
2016-08-12 0:19 ` Wu, Jiaxin
2016-08-12 8:27 ` Wu, Jiaxin
2016-08-12 12:34 ` Cohen, Eugene [this message]
2016-08-13 7:51 ` Wu, Jiaxin
2016-08-15 14:10 ` Cohen, Eugene
2016-08-16 1:27 ` Wu, Jiaxin
2016-08-16 19:44 ` Cohen, Eugene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AT5PR84MB0291D48234E2107AE8A16886B41F0@AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox