> -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Tuesday, November 10, 2015 3:54 AM > To: Leif Lindholm <leif.lindh...@linaro.org> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Wu, Jiaxin > <jiaxin...@intel.com> > Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > Importance: High > > On 11/10/15 11:43, Leif Lindholm wrote: > > On Tue, Nov 10, 2015 at 11:28:10AM +0100, Laszlo Ersek wrote: > >> On 11/10/15 11:20, Conen, Johannes wrote: > >>> Hmm, you're right..... is it briefly mentioned in the "ShellPkg > >>> Notes.txt" - I must admit, I only took a look at the > >>> "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major > changes > >>> to mentioned there (and well, they were, like the moving of the > >>> library files). So this non-backwards-compatibility from UDK2015 to > >>> UDK2014 regarding network-related stuff is intended? > >> > >> I'll have to let Jiaxin answer this question; I'm not a participant in > >> UDK feature planning. And, I have no idea how UDK releases account for > >> compatibility in general. > >> > >> (My *guess* is that UDK2015 generally targets (or moved towards) UEFI > >> 2.5, and Ip4Config (version 1) is apparently deprecated in UEFI 2.5.) > > > > The actual wording from the specification is: > > --- > > The EFI_IP4_CONFIG_PROTOCOL has been replaced with the new > > EFI_IP4_CONFIG2_PROTOCOL. > > • All new designs based on this specification should exclusively use > > EFI_IP4_CONFIG2_PROTOCOL . > > • The EFI_IP4_CONFIG_PROTOCOL will be removed in the next revision of > > this specification. > > --- > > > > Clearly this creates a compatibility breakage at some point. > > > > Is this something we consider "not a problem", or should the shell > > implement (providing a reference for how to implement) fallback to > > EFI_IP4_CONFIG_PROTOCOL if EFI_IP4_CONFIG2_PROTOCOL is not available? > > Whether the shell in edk2 should or should not provide fallback code for > EFI_IP4_CONFIG_PROTOCOL is for Intel to answer :), but I think I can ask > one more question as to "how". > > Namely, if one adds (or keeps) the Ip4Config fallback code to (in) the > shell in edk2, how does that compat feature get tested, staying within > the tree? It would require keeping the Ip4Config protocol implementation > around just for the sake of testing the fallback. > > I don't think that's a good idea. > > Instead, any dependencies on specific versions of the UEFI spec should > be spelled out loud and clear. (I believe I've read such requirements > presented by Windows, on MSDN.) Mapping each UDK release to a UEFI spec > version would be a bonus.
Seems like the short answer here is that the config command has a missing error condition/printout. If this has simply stated something like "the required protocol (EFI_IP4_CONFIG2_PROTOCOL) was not found." I think we would have gotten to the answer a lot closer. The intention was to replace support for EFI_IP4_CONFIG_PROTOCOL with EFI_IP4_CONFIG2_PROTOCOL, we do not believe that we can successfully maintain functional support for EFI_IP4_CONFIG_PROTOCOL. Should (used above) is one of those words where the meaning is vague. Should it do backwards compatibility and if so, for how long? -Jaben > > Thanks > Laszlo > > > > > Regards, > > > > Leif > > > >> Thanks > >> Laszlo > >> > >>> > >>> Greetings > >>> Johannes > >>> > >>> -----Ursprüngliche Nachricht----- > >>> Von: Laszlo Ersek [mailto:ler...@redhat.com] > >>> Gesendet: Dienstag, 10. November 2015 11:06 > >>> An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org > >>> Cc: Leif Lindholm (Linaro address) > >>> Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > >>> > >>> On 11/10/15 10:49, Conen, Johannes wrote: > >>>> Hi there, > >>>> > >>>> I made my tests with the binary shell from ShellBinPkg from UDK2014, > >>>> from UDK2015, the current master and a few commits in between and > >>>> rebuilt the shell from ShellPkg for UDK2014, UDK2015, the current > >>>> master and a few commits in between UDK2014 and UDK2015. > >>>> > >>>> It worked fine with r17868 and didn't work anymore with r17869, so it > >>>> has to be that commit (I of course rebuilt the shell from ShellPkg). > >>>> If I put both shells on a USB-stick and switch between them on the > >>>> fly, it works in the one built from r17868 and doesn't work in the one > >>>> built from r17869. Regarding ShellBinPkg: the last version that worked > >>>> is r17619 (which is quite logical since the version after that, > >>>> r18187, is built from ShellPkg r18186, which didn't work for me > >>>> anymore). > >>>> > >>>> I'm not working on OVMF, but on real hardware (X64) - don't know > >>>> exactly with which version the UEFI firmware was written, but I assume > >>>> it's UDK2014. I found nothing in the release notes that would break > >>>> backwards compatibility to firmware versions built with older EDKII > >>>> versions in this regard. > >>> > >>> Okay, that seems to explain it. The platform firmware on your physical > machine provides Ip4Config (version 1) only, but the shell built from recent > edk2 > (and probably the binary shipped in UDK2015) requires Ip4Config2. > >>> > >>> Hm... I have not been a UDK user, but now I downloaded > "UDK2015.Notes.zip", and in "ShellPkg Notes.txt", it says under "NEW FEATURES > AND CHANGES", point 15: > >>> > >>> Change "ping" and "ifconfig" code to consume Ip4Config2 protocol. > >>> > >>> So I think this has been (technically) documented in the UDK2015 release. > Perhaps the lack of compatibility with UDK2014 should have been emphasized. > >>> > >>> (But, I'm just a curious bystander in this discussion anwyay...) > >>> > >>> Thanks > >>> Laszlo > >>> > >>>> > >>>> With best regards, > >>>> Johannes Conen > >>>> > >>>> Siemens AG > >>>> Process Industries and Drives Division Process Automation > >>>> Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. > >>>> 50 > >>>> 76187 Karlsruhe, Germany > >>>> mailto:johannes.co...@siemens.com > >>>> > >>>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] > >>>> Gesendet: Dienstag, 10. November 2015 02:42 > >>>> An: Laszlo Ersek; Conen, Johannes; edk2-devel@lists.01.org > >>>> Cc: Leif Lindholm (Linaro address) > >>>> Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > >>>> > >>>> Hi Laszlo and Conen, > >>>> Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg > in UDK2015 release version, Both of them have included my patch for Ip4Config > Protocol deprecated work. > >>>> I'm also confused by the test result below, seems only time appeared > abnormal. > >>>> > >>>> Conen: Are you using the shell binary released in UDK2015? > >>>> > >>>> Thanks. > >>>> Jiaxin > >>>> > >>>> -----Original Message----- > >>>> From: Laszlo Ersek [mailto:ler...@redhat.com] > >>>> Sent: Tuesday, November 10, 2015 4:30 AM > >>>> To: Conen, Johannes; edk2-devel@lists.01.org > >>>> Cc: Leif Lindholm (Linaro address); Wu, Jiaxin > >>>> Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > >>>> > >>>> On 11/09/15 16:52, Conen, Johannes wrote: > >>>>> Hello everyone, > >>>>> > >>>>> after switching from UDK2014 to UDK2015, I noticed that the network > >>>>> commands (ifconfig / ping) don't work anymore. ifconfig just exits > >>>>> with no feedback and ping says "Config no mapping" (logical, as it is > >>>>> not possible to get an IP address via ifconfig). In UDK2014 everything > >>>>> worked fine. > >>>>> > >>>>> With the help of unixsmurf (thanks a lot) > >>>> > >>>> Argh. Can we stop using these "funny" nicks on IRC? > >>>> > >>>> "unixsmurf" is Leif. > >>>> > >>>> What do you think, Leif? :) > >>>> > >>>>> I went on bughunting and > >>>>> found out that commit r17869 / git sha > >>>>> 7c25b7ea5b2c029a9e7a0be57f7c20f31d720c7d broke it. Wild guess: it > has > >>>>> something to do with the new protocol. > >>>> > >>>> That's close, but my take is not that exact commit. Instead, what about > >>>> this: > >>>> > >>>> https://github.com/tianocore/edk2/commit/2aa0eb5df61e > >>>> > >>>> == SVN rev 17917. > >>>> > >>>> (I reviewed that commit.) > >>>> > >>>> But, it works for me: > >>>> > >>>>> Shell> ifconfig -s eth0 dhcp > >>>>> Shell> ifconfig -l eth0 > >>>>> > >>>>> ----------------------------------------------------------------- > >>>>> > >>>>> name : eth0 > >>>>> Media State : Media present > >>>>> policy : dhcp > >>>>> mac addr : 52:54:00:29:80:AE > >>>>> > >>>>> ipv4 address : 192.168.122.182 > >>>>> > >>>>> subnet mask : 255.255.255.0 > >>>>> > >>>>> default gateway: 192.168.122.1 > >>>>> > >>>>> Routes (2 entries): > >>>>> Entry[0] > >>>>> Subnet : 192.168.122.0 > >>>>> Netmask: 255.255.255.0 > >>>>> Gateway: 0.0.0.0 > >>>>> Entry[1] > >>>>> Subnet : 0.0.0.0 > >>>>> Netmask: 0.0.0.0 > >>>>> Gateway: 192.168.122.1 > >>>>> > >>>>> DNS server : > >>>>> 192.168.122.1 > >>>>> > >>>>> > >>>>> ----------------------------------------------------------------- > >>>>> Shell> ping 8.8.8.8 > >>>>> Ping 8.8.8.8 16 data bytes. > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=1 ttl=0 time=30640ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=2 ttl=0 time=31249ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=3 ttl=0 time=33280ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=4 ttl=0 time=38577ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=5 ttl=0 time=28432ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=6 ttl=0 time=31275ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=7 ttl=0 time=26576ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=8 ttl=0 time=33192ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=9 ttl=0 time=31112ms > >>>>> 16 bytes from 8.8.8.8 : icmp_seq=10 ttl=0 time=28237ms > >>>>> > >>>>> 10 packets transmitted, 10 received, 0% packet loss, time 312570ms > >>>>> > >>>>> Rtt(round trip time) min=26576ms max=38577ms avg=31257ms > >>>> > >>>> This on OVMF just built from edk2 at SVN rev18759. (Note that in OVMF > the shell is built from source as well.) > >>>> > >>>>> Personally I think this is a critical issue - it practically makes it > >>>>> impossible to use any network related stuff in the UEFI shell. > >>>> > >>>> I suspect that you are using an old (UDK2014) shell binary on top of a > >>>> new > (UDK2015) network stack, or vice-versa. > >>>> > >>>> If you check the commit message of SVN rev 17917 / git 2aa0eb5df61e, it > said that it was safe to remove the Ip4Config protocol *because* SVN rev > >>>> 17869 / git 7c25b7e [that you have found] had already moved ping / > ifconfig to the new protocol. > >>>> > >>>> And at the time of SVN rev 17869 / git 7c25b7e, the new protocol existed > (see SVN rev 17853 / git 1f6729ffe980). > >>>> > >>>> In chronological order: > >>>> - SVN rev 17853 / git 1f6729ff: implements the Ip4Config2 protocol, > >>>> - SVN rev 17869 / git 7c25b7ea: migrates ping & ifconfig to Ip4Config2, > >>>> - SVN rev 17917 / git 2aa0eb5d: removes Ip4Config (no more users) > >>>> > >>>> So, assuming you build *all* of your firmware from edk2, from source, > including the shell, you should end up with working ping & ifconfig at any > stage. > >>>> > >>>> I don't know at what stage UDK2015 was packaged. If it happened after > SVN rev 17917 / git 2aa0eb5d, then I guess the message of that commit > >>>> applies: "Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not > support original Ip4Config Protocol" -- please use a conformant shell I guess. > >>>> > >>>> I'm still a bit confused, because ShellBinPkg was also updated in SVN rev > 18187 / git 1fe76acc, which was about a month after SVN rev 17917 / git > 2aa0eb5d above. So unless Intel released UDK2015 exactly within that one > month, I cannot see how you can encounter this problem. > >>>> > >>>> Are you using a shell binary whose source is still based on UDK2014 (or > older)? > >>>> > >>>> Thanks, > >>>> Laszlo > >>>> > >>>> > >>>>> With best regards, > >>>>> Johannes Conen > >>>>> > >>>>> Siemens AG > >>>>> Process Industries and Drives Division Process Automation > >>>>> Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. > >>>>> 50 > >>>>> 76187 Karlsruhe, Germany > >>>>> mailto:johannes.co...@siemens.com > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> edk2-devel mailing list > >>>>> edk2-devel@lists.01.org > >>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>> > >>>> > >>> > >> > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
