Hey Petr, You have nailed it. :)
Now: Rpi + proxy success Rpi + noproxy success Efi + proxy success Efi + noproxy success BIOS + proxy success BIOS + noproxy success Thanks. @Alkis Georgopoulos <alk...@gmail.com> , @Jigish Gohil <jigish.go...@gmail.com> may give it a shot to reconfirm all scenario. Regards, Shrenik On Tue, 12 Oct, 2021, 09:58 Shrenik Bhura, <shrenik.bh...@gmail.com> wrote: > Thanks Petr for the detailed revert. > > I shall try again with the pxe-services branch and revert with my test > results. > > Meanwhile I am trying to answer few of your queries - > > > I have had trouble with proxy mode and I am not sure what is its > purpose. Do you know when proxy mode should be used? When is it required? > > proxy mode is being used when we have another server/router on the same > network that is handling dhcp and dhcp is not being done by dnsmasq > "authoritatively". Line 29 in ltsp-dnsmasq-proxy.conf > dhcp-range=set:proxy,192.168.2.0,proxy,255.255.255.0 takes care of that. > > > It does not rely on option 43 PXE menus support, just plain old DHCP > boot file. Requires dnsmasq to be the (authoritative?) DHCP server on the > network. > > I actually had no problem with proxy mode with the current stable release. > My only issues have been with non-proxy + efi scenarios. So what you have > suggested, already works for me. > > Just to clarify further - > When I am testing dnsmasq in non-proxy mode I use > ltsp-dnsmasq-noproxy.conf. > When I am testing dnsmasq in proxy mode I use ltsp-dnsmasq-proxy.conf. > The only difference is line 29 being commented or not respectively. I hope > you had made the switch of the configuration and had another device on your > network to serve dhcp requests. > > All the very best. > > > On Tue, 12 Oct 2021 at 07:12, Petr Menšík <pemen...@redhat.com> wrote: > >> Okay, sorry for omitting others. >> On 10/9/21 11:49, Shrenik Bhura wrote: >> >> Adding Alkis and Jigish back to the thread via cc. >> >> On Sat, 9 Oct 2021 at 15:18, Shrenik Bhura <shrenik.bh...@gmail.com> >> wrote: >> >>> Hey Petr, >>> >>> I have read your post a few times but am only partially able to >>> understand everything. It may be my lack of knowledge of the inner workings >>> of all things involved. I shall give it a go again later and even try the >>> patch. But where do you want me to apply the patch - on the master branch >>> or on your pxe-services branch ( >>> https://github.com/InfrastructureServices/dnsmasq/tree/pxe-services ) ? >>> >> That patch is against master from Simon's official repository. I have >> rebased that branch on github, the change is already there. You can just >> try that branch code as it is. That patch were more for Simon, because he >> does not merge remote branches directly. >> >> >>> Meanwhile, from a novice point of view and from what I know works in >>> dnsmasq, I have this query - >>> >>> Could dnsmasq not be made to ignore the pxe-service lines or bypass the >>> corresponding logic from the ltsp-dnsmasq.conf when >>> 1. is_tag_set("proxy") == "False" i.e ignore these lines - >>> >>> pxe-service=tag:proxy,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe >>> >>> pxe-service=tag:proxy,tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi >>> pxe-service=tag:proxy,tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe >>> pxe-service=tag:proxy,tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe >>> >> My change attempts to do exactly that. Current released code enables >> special handling when pxe-service is present in configuration. Without any >> relation about required tags for it. I have tried to modify it to require >> matching pxe-service to be found for current request. In a case any service >> does not match, it should fallback to classic DHCP. Could you try how much >> I were successful? This should work on my pxe-services branch. >> >> >>> 2. and when is_tag_set("rpi") == "False" i.e. ignore this line or >>> bypass corresponding logic - >>> pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused >>> when dnsmasq is processing a request in *non-proxy mode* and the >>> request is from *X86-64_EFI clients*? >>> >> Again, should work with my change. You should use a number to set a type, >> with 0 being order to boot from local disk instead. >> >> pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",0 >> >> Note other pxe-services should not match rpi tag, so only above is >> offered to RPi. >> >> >> pxe-service=tag:proxy,tag:!rpi,tag:!ipxe-ok,X86PC,"undionly.kpxe",ltsp/undionly.kpxe >> pxe-service=tag:proxy,tag:!rpi, >> tag:!ipxe-ok,X86-64_EFI,"snponly.efi",ltsp/snponly.efi >> pxe-service=tag:proxy,tag:!rpi, >> tag:ipxe-ok,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe >> pxe-service=tag:proxy,tag:!rpi, >> tag:ipxe-ok,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe >> >> >>> If possible, then everything would just work as expected for all >>> scenarios - *(BIOS or UEFI or RPI) and proxy*, *(BIOS or UEFI or RPI) >>> and non-proxy*. >>> It may be possible to handle this just within dnsmasq. >>> >> In ipxe.efi you have sent there seems to be missing support for menus >> defined by pxe-service (and option 43). That is a reason why pxe-service >> and pxe-prompt is there. If you don't need those menus, I would suggest >> using tags for dhcp-match=set:efi,option:client-arch,7 instead and using >> just pure dhcp-boot or dhcp-option=option:bootfile-name. Those should work >> more reliably and contrary to pxe-service should work also on IPv6. >> >> I were not successful booting with ipxe.efi built you sent and >> pxe-service=*,X86-64_EFI,*. It just did not work on my Lenovo laptop or >> brother's Dell. I don't have more machines to test EFI. pcbios mode worked >> fine with menus, their support is enabled in ipxe bios builds by default. >> >> >>> Please do consider this if not already done so. >>> >> I have had trouble with proxy mode and I am not sure what is its purpose. >> Do you know when proxy mode should be used? When is it required? It seems >> to be related to pxe-service, which I think does not work reliably on EFI. >> Should it be possible to offer PXEClient next-server and it would ask that >> server via pxe 4011 port? Do you need it somewhere in a real world? >> >> Would this config work instead, without any pxe-service enabled? >> >> # Specify the boot filename for each tag, relative to tftp-root. >> # If multiple lines with tags match, the last one is used. >> # See: https://www.syslinux.org/wiki/index.php?title=PXELINUX#UEFI >> dhcp-vendorclass=set:pxe,PXEClient >> dhcp-boot=tag:!rpi,tag:!ipxe-ok,tag:pxe,tag:X86PC,ltsp/undionly.kpxe >> dhcp-boot=tag:!rpi,tag:!ipxe-ok,tag:pxe,tag:X86-64_EFI,ltsp/snponly.efi >> dhcp-boot=tag:!rpi,tag:ipxe-ok,ltsp/ltsp.ipxe >> >> It does not rely on option 43 PXE menus support, just plain old DHCP boot >> file. Requires dnsmasq to be the (authoritative?) DHCP server on the >> network. >> >> Hope that helps. >> >> Cheers, >> Petr >> >> >>> Thanks, >>> Shrenik >>> >>> On Sat, 9 Oct 2021 at 03:43, Petr Menšík <pemen...@redhat.com> wrote: >>> >>>> I have made some attempts at PXE booting. I have to say, it is a mess. >>>> >>>> Put my booting attempts at fedorapeople [1]. I have asked on #ipxe IRC >>>> channel. It seems pxe-service works only on biospc, client-arch == 0. I >>>> were able to make simple menu on my father's lenovo desktop and my work >>>> Thinkpad 490s. One instance of Raspberry 3. In Legacy mode, it works >>>> somehow well. You are even to make local boot menu entries. I made it >>>> possible to boot to memtest just fine. >>>> >>>> However, any my attempt in EFI mode to boot using menus failed. There is >>>> special function pxe_uefi_workaround, but to me it did not work. Current >>>> code did never return reply from pxe port request. Because my laptop >>>> does not send option 43 stuff in ipxe.efi request and I have not used >>>> proxy, it just does not answer. I were able to make it return something. >>>> It seems not well supported and should be avoided. >>>> >>>> Guys at ipxe channel told me EFI does not include option 43 menu >>>> support, which seems to be true. At that results, I think pxe-service >>>> should be in general avoided if you want to support EFI. Just use tags >>>> to offer first boot-file as ipxe.efi, then use ipxe script with possible >>>> menus inside. That seems to be more reliable and well documented way. >>>> >>>> I have fixed previous patch, it has to offer just based on boot item >>>> supplied type. Client arch is not always sent in a request, even when it >>>> is always present in discover, as I have noticed in Shrenik's dumps. I >>>> think that patch makes improvement and allows pxe-service work just for >>>> platforms related. Others should use dhcp-file with tags, depending on >>>> their clients. >>>> >>>> Custom setting of tags depending on option:client-arch seems to be more >>>> understandable and reliable. >>>> >>>> I have had enough of PXE today. >>>> >>>> Cheers, >>>> Petr >>>> >>>> 1. https://pemensik.fedorapeople.org/dnsmasq/ >>>> >>>> On 10/7/21 23:10, Simon Kelley wrote: >>>> > As an aside the the discussion, can I just point out that I don't have >>>> > any way to test any of this dnsmasq functionality at the moment, and >>>> I'm >>>> > very rusty on the PXE spec, especially as it relates to EFI. >>>> > >>>> > I don't therefore have much to contribute to this discussion, but I do >>>> > think this is valuable work, and when you find a solution, I'll give >>>> the >>>> > resulting patchset my full attention. >>>> > >>>> > >>>> > Cheers, >>>> > >>>> > Simon. >>>> >>> -- >> Petr Menšík >> Software Engineer >> Red Hat, http://www.redhat.com/ >> email: pemen...@redhat.com >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >> >>
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
