@Michael
I stand corrected on option 66. I have confused myself with "next
server" comment in EFI code.
Bugzilla 2876
----------------
The more I get into the problem with a fresh mind and a cup of tea, the
more I realize that it is indeed a problem in reporters configuration.
Reporter stated:
- Failing scenario: tag 6 == 0x7
- Working scenario: tag 6 == 0x3
In the failing scenario, user sets bit 2 (so PXE_BOOT_SERVERS are being
used) and PXE_BOOT_SERVERS contains ProxyDHCP IP instead of TFTP server.
It should work fine if ProxyDHCP and TFTP sits on the same machine (with
the same IP).
Case closed, patch to be dropped, BZ to be rejected.
Philosophy / PXE Forced Mode
----------------
All I could find about 'PXE Forced Mode' is some non-spec
tooling/documentation.
https://knowledge.broadcom.com/external/article?legacyId=HOWTO7071
https://knowledge.broadcom.com/external/article/180499/pxe-forced-mode-utility.html
PDF from the first link's page sets up tag 6 to value 11 (bit 3, 1, 0
are set) and setting up tag 8 with some values.
Now I am sharing the shudder. Why is PXE_BOOT_SERVERS being used when
tag 6, bit 3 is set?
All I can blame is PXE spec being very vague on the matter or some kind
of ancient knowledge that I am not aware of.
Thanks,
Maciej.
On 21-Aug-20 11:11, Laszlo Ersek wrote:
On 08/20/20 15:41, Michael Brown wrote:
On 20/08/2020 11:44, Maciej Rabeda wrote:
@Michael
I am now wondering whether bit 3 is actually relevant to server choice.
Bit 3:
== 0 -> prompt user to choose a boot file. Which means to me: show
minimal menu with prompt (tag 10 - PXE_MENU_PROMPT) and options (tag 9
- PXE_BOOT_MENU).
== 1 -> do not prompt user. If boot file name is present (option 67),
download that boot file.
Bit 3 does not seem to specify/regulate which server to use.
Choice of server IP might look like:
if (option 43 is present, tag 6 is present, tag_6.bit_2 is set and tag
8 is present and valid)
take server IP from tag 8 (PXE_BOOT_SERVERS)
else if (option 66 is present)
take server IP from option 66 (TFTP server name)
else if (option 54 is present)
take server IP from option 54 (Server Identifier)
else
failure
RFC 2132 defines option 66 as a hostname (not an IP address): it is the
equivalent of the non-option "sname" field.
RFC 2132 defines option 54 as the DHCP server identifier, which is
unrelated to the TFTP server.
In the simple case (with no PXE menus involved), the TFTP server IP is
provided by the non-option "siaddr" field.
If option 60 is set to "PXEClient" and option 43 tag 9 is present and
option 43 tag 6 bit 3 is clear then this initiates a convoluted process
in which the user is first presented with an interactive menu
(constructed from the contents of option 43 tag 9) in order to select a
"boot server type", after which a second convoluted process is performed
to query the network using a protocol that is almost, but not quite,
entirely unlike DHCP. The TFTP server IP and boot filename are
eventually taken from the selected response packet in this final
almost-DHCP exchange.
*shudder*
I'll 100% defer to you and Maciej on this -- this is very complicated.
To begin with, I'm not fully clear what the purpose of edk2 git commit
ecec42044078 ("Update PXE driver to support PXE forced mode.",
2014-01-06) was.
What on Earth is "PXE forced mode"?
Siyuan, can you please explain?
And then I don't know whether the bug report at
https://bugzilla.tianocore.org/show_bug.cgi?id=2876
really has merit.
In the words of the reporter, the presently discussed patch would still
qualify as a "work-around", for making the PXE client ignore
PXE_BOOT_SERVERS, via clearing option#43 tag#6 bit#2 in the DHCP server
response. But IMO the more important question is whether it is valid for
the DHCP server (config) at their site to (a) populate PXE_BOOT_SERVERS,
(b) put (apparently!) the ProxyDHCP IP address in PXE_BOOT_SERVERS.
Like, I'd like to be convinced that the server config at the reporter's
site is not *invalid* in the first place. If it's invalid, then we
shouldn't be complicating the edk2 client code with a workaround. Even
if we adopted the workaround, the reporter would still have to
*activate* it, by manually clearing the bit in question (see at the very
end of <https://bugzilla.tianocore.org/show_bug.cgi?id=2876#c4>).
For me one big difficulty is that the PXE config options are scattered
about a forest of specs. Last time I spent more than an hour cursing and
hunting for them.
At Red Hat, over the last few years I've received an immense amount of
bug reports related to PXEv4/PXEv6 booting with edk2. In almost every
case, it was a bug in the reporter's server configuration. Yes,
anecdotal evidence. It makes me very reluctant to change the edk2 code,
especially that the reporter of TianoCore#2876 has seemingly stopped
communications.
Note how the bug report makes references to various attachments, such as
RAR files and one "Serva32.exe", regarding a reproducer. But until now,
with the latest comment being #9, those files have *not* been attached.
So it's not like we can set up some virtual machines on a virtual
network and fire up wireshark or tcpdump, to see the actual traffic.
I'm happy to pull out of this review session, as I trust you Michael and
Maciej to do the right here. I'm happy to offer some level of regression
testing, if you got new patches. I'd also be OK to simply close
TianoCore#2876 as INVALID (due to insufficient data).
Thanks
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#64534): https://edk2.groups.io/g/devel/message/64534
Mute This Topic: https://groups.io/mt/76290910/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
