From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ml01.01.org (Postfix) with ESMTP id A0A161A1DF2 for ; Wed, 10 Aug 2016 23:58:00 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 10 Aug 2016 23:58:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,503,1464678000"; d="scan'208";a="1033634187" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga002.jf.intel.com with ESMTP; 10 Aug 2016 23:58:01 -0700 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 10 Aug 2016 23:57:59 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx117.amr.corp.intel.com (10.18.116.17) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 10 Aug 2016 23:57:59 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.181]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.150]) with mapi id 14.03.0248.002; Thu, 11 Aug 2016 14:57:56 +0800 From: "Wu, Jiaxin" To: "Cohen, Eugene" , "edk2-devel@lists.01.org" Thread-Topic: IP4 Config Troubles with DHCP Thread-Index: AdHzLtnEw2gfDCBbQ1OtxXknLLKMhQAabX6g Date: Thu, 11 Aug 2016 06:57:57 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B7274137C5EF1@SHSMSX103.ccr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWE5ZTVkMDctMmFmNC00NzRhLWIxNDAtMmY0NWI0NWU5NWUwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlJCbm9GSjlSanF3UDJXdHNqNlJOSjVoamx1aXRNZm9UMStXSjE2eklpbTA9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: FW: IP4 Config Troubles with DHCP X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 06:58:00 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eugene, I want to confirm with you the steps to reproduce the issue: 1. Set policy to DHCP. 2. If DHCP process is not complete yet, then run one App to invoke the UDP4= Configure with "UseDefaultAddress =3D TRUE" (loop to keep calling Udp4->Co= nfigure until Ip4Mode.IsConfigured changes to TRUE) 3. Even DHCP succeed but Ip4Mode.IsConfigured flag never set to TRUE --= -- failure here!!! Above steps right?=20 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 =3D Nlc->Udp4->Configure(Nlc->Udp4, &Nlc->UdpConfig); if (EFI_ERROR (Status) && (Status !=3D EFI_NO_MAPPING)) { return Status; } if (Status =3D=3D EFI_NO_MAPPING && !UdpGetMapping (Nlc->Udp4)) { return Status; } In UdpGetMapping () function, create one timer to check Ip4Mode.IsConfigure= d: For example: UdpGetMapping () { IsMapDone =3D 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 =3D TRUE; break; } } return IsMapDone; } If DHCP process succeed, Ip4Mode.IsConfigured should be updated. If not, an= y bug may be existed. Thanks, Jiaxin -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohe= n, Eugene Sent: Thursday, August 11, 2016 2:14 AM To: edk2-devel@lists.01.org; Wu, Jiaxin Subject: [edk2] IP4 Config Troubles with DHCP We have been running into an issue when trying to configure an interface as= DHCP where if the DHCP process is not yet complete (Ip4Mode.IsConfigured i= s FALSE) the configure process will never succeed. We have a case where we attempt to invoke the UDP4 Configure: Status =3D Nlc->Udp4->Configure(Nlc->Udp4, &Nlc->UdpConfig); We had a retry loop where we keep calling Udp4->Configure until we finally = see Ip4Mode.IsConfigured go TRUE (similar to what you see in Mtftp4GetMappi= ng) - this has worked for many years but recently something broke this. N= ow, even when DHCP succeeds the Ip4Mode.IsConfigured flag is set to FALSE. = =20 Only if we retry by destroying and re-creating new service binding children= can we actually get this logic to succeed. This logic is getting ridiculo= usly complicated so I'm thinking there has to be a better way of doing this= . Do you have an example of specifically how a driver/app should handle the c= ase where the DHCP process is not yet complete and wants to wait? Thanks, Eugene _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel