[edk2,1/4] MdeModulePkg: Change the default IPv4 config policy

Message ID CAD0U-hLVW2kTfUYBP9=o+1ONL9Ed3uw1Dz2djBbh067GurEBAA@mail.gmail.com
State New
Headers show

Commit Message

Ryan Harkin June 21, 2016, 6:12 p.m.
Hi Jiaxin,

On 21 June 2016 at 12:20, Ryan Harkin <ryan.harkin@linaro.org> wrote:
> Hi Jiaxin,


> On 21 June 2016 at 12:10, Wu, Jiaxin <jiaxin.wu@intel.com> 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:

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__, Instance->Policy));

Therefore, I can trace which branches the code is taking.

On first boot, as expected, I can see that Ip4StartAutoConfig is not
called at all.  The default policy is static, so I'd expect that.

Then, when I configure DHCP from Shell, I see the following debug:

Ip4StartAutoConfig:921 Instance->Policy=0
Ip4StartAutoConfig:1032 Instance->Policy=0

This tells me that NetLibCreateServiceChild, gBS->OpenProtocol and
Dhcp4->Configure succeeded and the DHCP process was started.

That all looks good.  So I reset the board and see this debug on boot:

Warning: LAN9118 Driver in stopped state
Ip4StartAutoConfig:921 Instance->Policy=1
Ip4StartAutoConfig:943 Instance->Policy=1
Ip4StartAutoConfig:947 Instance->Policy=1
Ip4StartAutoConfig:958 Instance->Policy=1
Ip4StartAutoConfig:921 Instance->Policy=1
Ip4StartAutoConfig:943 Instance->Policy=1
Ip4StartAutoConfig:958 Instance->Policy=1
Ip4StartAutoConfig:921 Instance->Policy=1
Ip4StartAutoConfig:962 Instance->Policy=1
Ip4StartAutoConfig:1032 Instance->Policy=1
EhcExecTransfer: transfer failed with 2
EhcControlTransfer: error - Device Error, transfer - 2
Press ENTER to boot now or any other key to show the Boot Menu in 8 seconds

Booting EFI USB Device
Booting EFI Misc Device
Booting EFI Misc Device 1
Booting EFI Network
..PXE-E99: Unexpected network error.
Booting EFI Internal Shell
Loading driver at 0x000F86C3000 EntryPoint=0x000F86C4000 Shell.efi

Shell> ifconfig -s eth0 dhcp
Ip4StartAutoConfig:921 Instance->Policy=0
Ip4StartAutoConfig:924 Instance->Policy=0

So I can see that on boot, because the saved policy is DHCP, the code
taking a few error branches.

First off "NetLibCreateServiceChild" returns EFI_UNSUPPORTED.  The
comments say this means "No DHCPv4 Service Binding protocol, register
a notify.".  Dhcp4SbNotifyEvent is NULL, so we create a notify event.

There could be a bug here, I suppose.  Why is NetLibCreateServiceChild
returning EFI_UNSUPPORTED?  I guess I need to investigate this some

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.

I applied this diff to fix the suspected bug:

Now, after first boot, I see this output when I run "ifconfig -s eth0
dhcp".  Basically the same as before:

Shell> ifconfig -s eth0 dhcp
Shell> tAutoConfig:921 Instance->Policy=0
Ip4StartAutoConfig:1030 Instance->Policy=0

Then, I reset the board and then it ASSERTs:

Warning: LAN9118 Driver in stopped state
Ip4StartAutoConfig:921 Instance->Policy=1
Ip4StartAutoConfig:943 Instance->Policy=1
Ip4StartAutoConfig:947 Instance->Policy=1
Ip4StartAutoConfig:960 Instance->Policy=1

ASSERT_EFI_ERROR (Status = Invalid Parameter)
!EFI_ERROR (Status)

This is because gBS->OpenProtocol returns Invalid Parameter.

So it looks like my diff wasn't a bug fix at all.  Or, there is another bug?

What do you think?

edk2-devel mailing list


diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index a1de443..fb8a46a 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -953,9 +953,7 @@  Ip4StartAutoConfig (
-  }
-  if (EFI_ERROR (Status)) {
+  } else if (EFI_ERROR (Status)) {
     return Status;