@Alkis Georgopoulos <alk...@gmail.com> Though no changes may be needed in the existing ltsp-dnsmasq.conf, I just recalled that I had made some modifications (lines 35-54) in mine for the sake of clarity for any future hardware specific scenarios that I may encounter. Herein is attached the no-proxy version of the same.
On Fri, 15 Oct 2021 at 18:41, Shrenik Bhura <shrenik.bh...@gmail.com> wrote: > No changes need in ltsp-dnsmasq.conf . Just checked out from Petr's > branch, compiled and replaced /usr/sbin/dnsmasq with the new one. > > Regards, > Shrenik > > On Fri, 15 Oct, 2021, 17:16 Alkis Georgopoulos, <alk...@gmail.com> wrote: > >> @Petr, thank you very much for troubleshooting this! >> >> @Shrenik, are any changes required in ltsp-dnsmasq.conf? >> Or we just need to apply Petr's patch, compile/install, and it works? >> Thank you as well for your persistence and testing! >> >> Cheers, >> Alkis >> >> On 10/15/21 2:42 PM, Shrenik Bhura wrote: >> The below response is to be read in the thread prior to the "all success >> scenario" email. >> >> Apologies for the confusion but I only realised now that the post went >> off-list just to Petr. >> >> Regards, >> Shrenik >> >> ---------- Forwarded message --------- >> From: *Shrenik Bhura* <shrenik.bh...@gmail.com >> <mailto:shrenik.bh...@gmail.com>> >> Date: Tue, 12 Oct, 2021, 09:58 >> Subject: Re: [Dnsmasq-discuss] [PATCH] Re: pxe-service entries in >> dnsmasq conf seem to fail non-proxy EFI boot >> To: Petr Menšík <pemen...@redhat.com <mailto:pemen...@redhat.com>> >> >> >> 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 takescare 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 >> <mailto: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 <mailto: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 >> > >> <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 >> <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 >> > <mailto: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/ >> > <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/ <http://www.redhat.com/> >> email:pemen...@redhat.com <mailto:pemen...@redhat.com> >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >> >> >>
ltsp-dnsmasq-noproxy.conf
Description: Binary data
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
