<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I could not find any relevant difference between nuc-efi.pcapng
      and qemu-efi.pcapng responses. They seem very similar. Yet qemu
      continues with TFTP download and next step. Nuc does not react
      anyhow to boot offer. It seems to not download or start
      snponly.efi. It seems to me the answer lies only on its boot rom
      firmware. I just expect both used matching configuration and
      dnsmasq version.</p>
    <p>From dnsmasq side, answer to DHCP discover and request contains
      expected value in expected format. Critical is any output of NUC
      when it receives the offer. Does it fail with any error code? Does
      it print any error? At least screenshot would be useful. It seems
      to me the problem is somewhere in its PXE implementation, which we
      cannot solve in dnsmasq. Because it even does not try to download
      and execute snponly.efi, even iPXE build with debug logs (which I
      am not sure how to enable btw) would not help.</p>
    <p>What kind machine it is? Does it have the latest bios firmware
      available? Would this machine boot at least snponly.efi if
      pxe-service were commented out? It seems similar to previous
      intel_nuc_efi_with_ltsp-pxeservice.pcapng file requests, but it
      does use proxyDHCP requests like the old one. How changed dnsmasq
      configuration to make this change? How does dnsmasq.conf look like
      for it?</p>
    <p>Option 43 suboption PXE discovery control (6) is different now.
      It seems not well received by PXE firmware this time. Used config
      file of dnsmasq is not attached this time, I can only guess. HW
      address is different, not sure how different is used machine.</p>
    <p>Was it this machine, which returned <span class="term"><tt>PXE-E21:
          Remote boot cancelled.? Returned control to LoadFile control
          seems suspicious. May it require non-efi image instead? If you
          can reach support for this machine, I think it might be
          reported to them. Especially about how PXE menu can specify
          Local Boot?<br>
        </tt></span></p>
    <p><span class="term"><tt>I am afraid I don't know how to help now.
          If one machine can boot with the same setup that another
          cannot, it is up to you to find commonly working
          configuration.<br>
        </tt></span></p>
    <div class="moz-cite-prefix">On 9/30/21 12:47, Shrenik Bhura wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANKp9xeQViN_6csC6OU8xGSQ1t7AT_AZNwrZW+C0m5zYvJ6SRg@mail.gmail.com">
      <div dir="ltr">
        <div id="gmail-:1zw" class="gmail-a3s gmail-aiL">
          <div dir="ltr">
            <div dir="ltr"><span class="gmail-im">
                <div>> 1. seems to have wrong pcap file or it does
                  not use configuration attached in linked archive. It
                  seems it offers menu items from 2. archive with custom
                  pxe-services. <br>
                </div>
                <div><br>
                </div>
              </span>
              <div>Apologies, there was definitely some mistake.</div>
              <div><br>
              </div>
              <div>We have applied the patch and tried with and without
                dhcp-no-override but it still fails to boot. Herein are
                the pcap and the logs for this case. <br>
              </div>
              <div><a
href="https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing"
                  moz-do-not-send="true" class="moz-txt-link-freetext">https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing</a></div>
              <div><br>
              </div>
              <div>Additionally, also included is the qemu pcap wherein
                it does boot successfully.</div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, 29 Sept 2021 at 20:29,
          Petr Menšík <<a href="mailto:pemensik@redhat.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">pemensik@redhat.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote">
          <div>
            <p>It is somehow hard to guess described results for each
              configuration (1. 2. 3.). It is unclear to me, what you
              saw for each variant printed by the computer.</p>
            <p>1. seems to have wrong pcap file or it does not use
              configuration attached in linked archive. It seems it
              offers menu items from 2. archive with custom
              pxe-services.<br>
            </p>
            <p>Option 43 Suboption: (9) PXE boot menu<br>
                  Length: 41<br>
                  boot menu:
8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820…<br>
                      Type: Unknown (32768)<br>
                      Length: 21<br>
                      Description: PXELINUX (X86-64_EFI)<br>
                      Type: Unknown (32769)<br>
                      Length: 14<br>
                      Description: PXELINUX (EFI)<br>
            </p>
            <p>Above is not present in config file presented for it, but
              in 2. Are you sure you have killed dnsmasq and started it
              again?<br>
            </p>
            <p>I think it might be difference between pxe-service served
              file chosen via menuboot. I have noticed there are two way
              to specify file to boot in DHCP for IPv4. One is in fixed
              header and first try chosen from menu is in that.
              pxe-service options makes it to request direct query to
              DHCP server, marked proxyDHCP in wireshark. This proxy ACK
              is followed by TFTP.</p>
            <p>I used filter in wireshark: "dhcp or
              (!tftp.destination_file && tftp)"<br>
            </p>
            <p>However following DHCP offers boot file path ONLY in
              option 67 value. Fixed header boot file is all zeroed. It
              seems to me this is the part the snponly.efi firmware does
              not understand. It does not try to use path in option, but
              may insist only on file. Since option #52 overload is not
              in packet, I guess dnsmasq should have used mess->file
              for path and not option 67. But rules of rfc2131.c:2476
              are simple. If client have requested option 67, it should
              handle it as option 67. I guess it is bug in snponly.efi.
              Either it should not include option 67 between requested
              options or it should actually handle the option. Dnsmasq
              would offer boot path in both cases.</p>
            <p>Interesting enough, dnsmasq is inconsistent with itself.
              It behaves a bit different way in PXE proxy mode, where
              file header part is always used. In normal mode unless
              --dhcp-no-override is used, option is used if requested.</p>
            <p>Can you please try if dhcp-no-override option would fix
              your issues? I think it should behave the same way in both
              situations.</p>
            <p>I attached patch, which would set boot file on
              pxe-service the same way as dhcp-boot. It may require
              dhcp-no-override where it did not before. Could you please
              try it?<br>
            </p>
            <pre cols="72">
</pre>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
  </body>
</html>