From: "Wu, Jiaxin" <jiaxin.wu@intel.com>
To: "Cohen, Eugene" <eugene@hp.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: IP4 Config Troubles with DHCP
Date: Tue, 16 Aug 2016 01:27:47 +0000 [thread overview]
Message-ID: <895558F6EA4E3B41AC93A00D163B7274137C7C7A@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <AT5PR84MB0291C783DF0E7E53AABE9B6CB4120@AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM>
> > Actually, you don't need to retry the UDP configuration loop according
> > the Ip4Mode.IsConfigured flag. You are only recommended to set a timer
> > to check the mapping status after the configuration:
> >
> > For example:
> > Status = Nlc->Udp4->Configure(Nlc->Udp4, &Nlc->UdpConfig);
> > if (EFI_ERROR (Status) && (Status != EFI_NO_MAPPING)) {
> > return Status;
> > }
> > if (Status == EFI_NO_MAPPING && !UdpGetMapping (Nlc->Udp4)) {
> > return Status;
> > }
> >
> > In UdpGetMapping () function, create one timer to check
> > Ip4Mode.IsConfigured:
> >
> > For example:
> > UdpGetMapping () {
> > IsMapDone = FALSE;
> > gBS->CreateEvent (EVT_TIMER, TPL_CALLBACK, NULL, NULL,
> > &TimeoutEvent);
> > gBS->SetTimer (TimeoutEvent, TimerRelative, AnyValue);
> > while (EFI_ERROR (gBS->CheckEvent (TimeoutEvent))) {
> > Udp4->Poll (Udp4);
> > Udp4->GetModeData (Udp4, &Udp4Mode, & Ip4Mode, NULL, NULL);
> > if (Ip4Mode.IsConfigured) {
> > IsMapDone = TRUE;
> > break;
> > }
> > }
> > return IsMapDone;
> > }
> >
> > If DHCP process succeed, Ip4Mode.IsConfigured should be updated. If
> > not, any bug may be existed.
>
> In testing the new patch (removing RECONFIG=TRUE) I see that the
> statement you made above is not accurate when the protocol is TCP. When
> Configure is called the first time it returns EFI_NO_MAPPING. This seems to
> be remembered in the socket state: ((Sock)->ConfigureState ==
> SO_NO_MAPPING) so that any attempt to use the instance after
> Ip4Mode.IsConfigured goes TRUE fails (like for a TCP4 Listen).
>
> So for TCP we must issue another Configure request to clean up this state so
> it's not as simple as just polling the GetModeData result, at least for TCP.
Yeah. When I was drafting the UDP APP to test the new fix, I found the same case you mentioned. We must issue another UDP Configure () to clean the previous state once the Ip4Mode.IsConfigured is TRUE. So, the above example is not accurate with my the current implementation:(. But I'm still not recommend to loop the UDP configuration every time if Ip4Mode.IsConfigured is false. The right behavior for UDP/TCP is 1) timer check the Ip4Mode.IsConfigured, 2) Once Ip4Mode.IsConfigured is TRUE, reconfigure the instance again. Sorry for the above example was troubling you. Also use UDP as example, correct as below:
Udata.UseDefaultAddress = TRUE;
Status = Udp4->Configure (Udp4, &Udata);
if (EFI_ERROR (Status) && (Status != EFI_NO_MAPPING)) {
return Status;
}
if ((Status == EFI_NO_MAPPING) && !UdpGetMapping (Udp4, &Udata)) {
return Status;
}
In UdpGetMapping () function:
BOOLEAN
UdpGetMapping (
IN EFI_UDP4_PROTOCOL *Udp4,
IN EFI_UDP4_CONFIG_DATA *UdpCfgData
)
{
EFI_STATUS Status;
EFI_EVENT TimeoutEvent;
EFI_IP4_MODE_DATA Ip4ModeData;
BOOLEAN IsMapDone;
IsMapDone = FALSE;
ZeroMem (&Ip4ModeData, sizeof (EFI_IP4_MODE_DATA));
Status = gBS->CreateEvent (EVT_TIMER, TPL_CALLBACK, NULL, NULL, &TimeoutEvent);
if (EFI_ERROR (Status)) {
return IsMapDone;
}
//
// Start the timer, it will timeout after 5 seconds.
//
gBS->SetTimer (TimeoutEvent, TimerRelative, 500000000);
while (EFI_ERROR (gBS->CheckEvent (TimeoutEvent))) {
Udp4->Poll (Udp4);
if (!EFI_ERROR (Udp4->GetModeData (Udp4, NULL, &Ip4ModeData, NULL, NULL)) &&
Ip4ModeData.IsConfigured) {
Udp4->Configure (Udp4, NULL);
IsMapDone = (BOOLEAN) (Udp4->Configure (Udp4, UdpCfgData) == EFI_SUCCESS);
break;
}
}
gBS->CloseEvent (TimeoutEvent);
return IsMapDone;
}
>
> Do you believe this is expected behavior?
>
> Thanks,
>
> Eugene
>
next prev parent reply other threads:[~2016-08-16 1:27 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
2016-08-13 7:51 ` Wu, Jiaxin
2016-08-15 14:10 ` Cohen, Eugene
2016-08-16 1:27 ` Wu, Jiaxin [this message]
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=895558F6EA4E3B41AC93A00D163B7274137C7C7A@SHSMSX103.ccr.corp.intel.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