Re: DHCP Automatic Configure at Driver Connect

["Wu, Jiaxin" <jiaxin.wu@intel.com>]

Eugene,

> > > > In my memory, we only talked about the performance issue before.
> > > > Here, I understand your requirement: 1) The network interface
> > > > should be in
> > > > *un-
> > > > configured* status at each boot time until the third part
> > > > configuration;
> 
> Yes, we would like a policy setting (either runtime/protocol or build-
> time/PCD is fine) for this.
> 
>  2) the policy setting should be ignored, right? I
> > > > don't
> 
> I don't know what you mean by this.  The static/dhcp policy shouldn't
> necessarily be ignored but if the interface is not yet configured (i.e. the IP
> layer won't respond to packets) then the static/dhcp policy doesn't really
> matter until some component calls Configure() for the first time.

I mean I didn't know whether the *un-configured* status you want contain *no policy setting * or not. But it doesn't matter now, from your statement here, I know you don't care the policy setting.

> 
> > This is what I want to confirm with you that my understanding is
> > right? You complained the network interface comes "up" at each boot,
> > what does "comes up" exactly mean? So, I gave the above two guesses 1)
> and 2).
> 
> And I tried to clarify what I meant.  Another way of saying it is by being "up" it
> means performing DHCP (if that is the setting) and transmitting/receiving
> packets using the IP address.  What we are asking for is a policy where we
> can suppress this behavior until the first Configure() call like before.

As I said in previous email, " The current behavior of Ip4Config2: DHCP policy together with D.O.R.A process, which is the same case as the old Ip4Config behavior ". From the case you described here, are you want to separate the DHCP policy setting and D.O.R.A process? We don't know.

> 
> > Of course not. I mean if my guessing 2) is correct, it's not
> > reasonable because UEFI 2.6 spec only defined Static/DHCP policy. The
> > policy should be in one of them. I just recalled the old Ip4Config
> > behavior: no policy assigned default (if I remember correctly).  So,
> > don't misunderstand my truly means. It's unrelated to the *behavior
> consistency*.
> 
> Perhaps not spec consistency but we need this for implementation
> consistency since we've built up years of expectations from the previous
> implementation.

We also don't know what is the *specific/explicit* *implementation consistency* you want here. Can you describe it more detail? I know the one difference between the old Ip4Config and Ip4Config2 is about the policy assignment. The old Ip4Config has no policy assigned default but currently we have the default one according the UEFI2.6. I think this difference is enrolled by the Spec updated. And this is also why I have the guess 2).  

> 
> > First, *based on the current UEFI Spec (only static / dhcp policy)*, I
> > want to highlight my understanding of *un-configured* status you
> > mentioned: policy should be always set, *un-configured* means *no IP
> address configuration*.
> 
> Correct, in that the device will neither transmit or respond at an IP layer
> initially.

Ok, that's fine.


> 
> > If we want to implement such a *un-configured* state, one *DXE_DRIVER*
> > can be used with Ip4Config2 protocol. Detailed see below pseudocode:
> >
> > First,  register a notify for Ip4Config2 protocol in your Dxe Driver EntryPoint:
> >     EfiCreateProtocolNotifyEvent (
> >         &gEfiIp4Config2ProtocolGuid,
> >         TPL_CALLBACK,
> >         Ip4Config2InstalledCallback,
> >         NULL,
> >         &Registration
> >         );
> >
> > Then, In your Ip4Config2InstalledCallback() function, you can change
> > the default policy for the current boot:
> >      Ip4Config2InstalledCallback () {
> >          gBS->LocateProtocol (
> >               &gEfiIp4Config2ProtocolGuid,
> >               Registration,
> >               (VOID **) &Ip4Config2Instance
> >               );
> >
> >          //
> >          // Change the policy to Ip4Config2PolicyDhcp to clean the static setting.
> >         //
> >         Policy = Ip4Config2PolicyDhcp;
> >         Ip4Config2Instance->SetData(
> >                                                         Ip4Config2Instance,
> >                                                         Ip4Config2DataTypePolicy,
> >                                                         sizeof (EFI_IP4_CONFIG2_POLICY),
> >                                                         &Policy
> >                                                         );
> >
> >          //
> >          // Change the policy to Ip4Config2PolicyStatic to clean the
> > DHCP policy setting.
> >         //
> >         Policy = Ip4Config2PolicyStatic;
> >         Ip4Config2Instance->SetData(
> >                                                         Ip4Config2Instance,
> >                                                         Ip4Config2DataTypePolicy,
> >                                                         sizeof (EFI_IP4_CONFIG2_POLICY),
> >                                                         &Policy
> >                                                         );
> >     }
> >
> > After that, your previous setting will be cleaned, and reach a  *un-
> > configured* state. I know the addition Dxe Driver is an indirect way
> > to meet your requirement, but based on current UEFI Spec, it's
> > one-time event if you added in  your platform ahead.
> 
> There's two issues I see with this approach:
> 
> 1. It destroys any previous configuration data that the user may have made
> (static IP entry or explicit selection of DHCP) 2. It's a hack where we're using
> one policy interface to try to accomplish something unrelated (auto vs on-
> demand config) based on attributes of the current implementation and not
> the spec
> 

The provided solution for you (such a DXE Driver) is only based on you want an *un-configured* status at each boot time until the third part configuration. I think it does an approach for this. But I think Ting is right, "we need fully understand your usage case before analyzing the problem". Perhaps you have more detailed requirements we don't know clearly.


> So I'd like to propose again that we define another, separate, policy value for
> automatic versus on-demand IP configuration.  It can be either through a PCD
> or a protocol interface.  My preference in the short term is to do the PCD
> thing since we can do it now where the protocol approach will require spec
> modification.
> 
> Let me know if that makes sense - I'm prepared to provide a patch for the
> PCD option if/when you're ready.
> 
> Eugene
>