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

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:
364f4efa444150df3f074f563374dce1e153adc6

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
add-symbol-file
/working/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
0xF86C4000
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
more.

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)
ASSERT [Ip4Dxe]
/working/platforms/uefi/edk2/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c(972):
!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?

Regards,
Ryan.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel