> 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
