Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi Petr, Is there anything else needed from me on this to diagnose this further? Last I had shared the log and pcap corresponding to the case 1. i.e., pxe-service entries with tag:proxy with dhcp-boot . Regards, Shrenik On Thu, 30 Sep, 2021, 16:17 Shrenik Bhura, wrote: > > 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. > > Apologies, there was definitely some mistake. > > 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. > > https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing > > Additionally, also included is the qemu pcap wherein it does boot > successfully. > > On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: > >> 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. >> >> 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. >> >> Option 43 Suboption: (9) PXE boot menu >> Length: 41 >> boot menu: >> 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… >> Type: Unknown (32768) >> Length: 21 >> Description: PXELINUX (X86-64_EFI) >> Type: Unknown (32769) >> Length: 14 >> Description: PXELINUX (EFI) >> >> Above is not present in config file presented for it, but in 2. Are you >> sure you have killed dnsmasq and started it again? >> >> 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. >> >> I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" >> >> 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. >> >> 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. >> >> Can you please try if dhcp-no-override option would fix your issues? I >> think it should behave the same way in both situations. >> >> 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? >> On 9/28/21 11:54, Shrenik Bhura wrote: >> >> Hi Petr, >> >> As per your guidance, we have enabled logging (LOG_ALL in >> config/consolle.h) and recompiled the ipxe binaries. Below are the latest >> observations. >> >> Taking down the scenarios from the previous post for ease of reference - >> 1. Default dnsmasq config with default ltsp's pxe-service entries - >> https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing >> 2. Custom pxe-service entries (just to prove that pxe-service and >> dhcp-boot do seem to successfully co-exist) - >> https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing >> 3. Without pxe-service entries - >> https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing >> >> I'll try to summarise the understanding and prevailing ambiguities thus >> far to help allot responsibility of multiple things that may be going wrong >> here : >> >> Between scenario (1) and (2), we see that ltsp.ipxe is being served in >> (2) which doesn't happen in (1). >> In (1), the primary issue is that EFI clients do not receive snponly.efi, >> thus they do not advertise option 175 and hence are not sent the ltsp.ipxe. >> Since it has not got to the iPXE stage as yet, there are no logs available >> from ipxe. All that is visible momentarily on the client side is these two >> lines - >> >> *Station IP address is 192.168.67.134 * >> *PXE-E21: Remote boot cancelled.* >> Quoting from an explanation herein [1] for "Remote boot cancelled" - >> *" This message is also displayed when a D
[Dnsmasq-discuss] unittests
In-Reply-To: <8a018620-25a7-a292-c951-dd2017d54...@redhat.com>
On Mon, May 03, 2021 at 12:53:39PM +0200, Petr Menšík wrote:
> On 4/30/21 12:42 AM, Simon Kelley wrote:
> > On 14/04/2021 18:35, Petr Menšík wrote:
> >> Hi Simon and other dnsmasq friends,
> >>
> >> after some struggling with Makefile support, I am sending my dnsmasq
> >> unit tests. It uses another directory with tests specific code. I moved
> >> some common parts to Makefile.config, in order to be able to reuse them.
> >> Unit tests are under tests directory with own Makefile.
> >>
> >> New target make check should work also from top directory. Some checks
> >> would work only from tests directory (make kyua). Current coverage is
> >> rather poor, but I hope can be used as a building block to better tests.
> >> Especially option parsing tests are easy to write. Testing of sending
> >> and receiving packets seems to be difficult, it should be tested by
> >> different kind of test IMHO.
> >>
> >> First is attempt to refactor, the second is what evolved into more
> >> complex set of tests.
> >>
> >> Original separate commits are still available on github [1].
> >>
> >> What do you think?
> >
> > Well, I applied the patch, and run "make check" and all the tests passed!
> >
> > Now I have to understand how to write new tests.
>
> Configuration parsing tests are easy, just provide input parameters
> similar way to existing test and then check expected values are provided.
> >
> > Would it make sense to consider some changes to the main code to make
> > the tests easier? I see that die() is a problem. Can we change the code
> > in die() to do something useful when testing?
>
> I have chosen to omit dnsmasq.c code from tests. It contains main()
> function, cannot be part of test anyway. Sure, some code changes would
> help with reducing needed repetitions in tests. Especially init code
> required in tests should be moved out of dnsmasq.c, where it could be
> called directly from tests. Shared init code must not be static
> functions of course.
>
> die does make sense everywhere where it is a corner case. If we move
> die() calls to dnsmasq.c, it would be okay. Other files should return
> indication of fatal error, but not die directly. It would need
> additional wrappers in dnsmasq.c, but such functions would be more testable.
> >
> > Also the tests seem to can copies of initialisation code, does it make
> > sense to abstract the initialisation in main() so that it can be used by
> > the tests standalone?
> Yes, it make sense to move parts of initialization to subsystem-specific
> initialization functions. I would move dns_init() into rfc1035.c,
> dhcp_init() into dhcp-common.c etc. It should make main source file
> shorter and it would be more obvious, which subsystems are initialized
> in which order, whether they depend on anything before it. I think the
> best practice is to break long functions into several shorter, more
> readable functions. I think current main() is a great example to break
> into more smaller functions and move some of them to shareable files.
> Parts required by current tests are small enough.
> >
> > I'm thinking of changing the existing main()
> >
> > main()
> > {
> >
> > while (1)
> > events()
> > }
> >
> > into
> >
> > main()
> > {
> > init();
> > while (1)
> > events()
> > }
> >
> > So that init() is available for testing.
> >
> >
> > Cheers,
> >
> > Simon.
> >
> >>
> >> PS: sending this message again, because patch #2 were big enough to
> >> require moderator's approval. Compressed it as a workaround.
> >>
> >> Cheers,
> >> Petr
> >>
> >> 1. https://github.com/InfrastructureServices/dnsmasq/tree/unittests
>
What was / is the posting from Simon asking something
Would unittest have detect this side-effect of the change?
I couldn't find it, but could find the above posting.
Reason for starting a fresh thread is for
having fresh attention for unittests.
Groeten
Geert Stappers
--
Silence is hard to parse
signature.asc
Description: PGP signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] HA Cluster - IPv6 router adv lifetime of 0
Jochen Demmer via Dnsmasq-discuss schreef op 2021-10-02 10:28: Hi, I've been trying to develop my own kind of firewall solution named nftwall which uses nftables as packet filter and is being managed centrally by Ansible - no webGUI. My first attempt was to use dnsmasq but then I found out of this obstacle. I've been thinking about switching to KEA + radvd but actually I would like to keep using dnsmasq. I manage my VRRP IPs with keepalived. There are small scripts for an event of a primary - secondary change. Especially in an event of controlled switch of primary - secondary I would like the primary dnsmasq to send a lifetime of 0 in the router advertisement package. That way the clients know that this router shall not be used any more. No experience with RAs so far, but isn't that what the priority field is for? Please confirm my findings that this is currently not possible with dnsmasq. If so please accept my feature request to implement that. Regards Jochen Demmer ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- With kind regards, William Edwards ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] HA Cluster - IPv6 router adv lifetime of 0
On Sat, Oct 02, 2021 at 10:28:16AM +0200, Jochen Demmer via Dnsmasq-discuss wrote: > > Hi, Welcome, > I've been trying to develop my own kind of firewall solution named > nftwall which uses nftables as packet filter and is being managed > centrally by Ansible - no webGUI. > > My first attempt was to use dnsmasq but then I found out of this > obstacle. I've been thinking about switching to KEA + radvd but actually > I would like to keep using dnsmasq. > I manage my VRRP IPs with keepalived. There are small scripts > for an event of a primary - secondary change. Especially in an > event of controlled switch of primary - secondary I would like the > primary dnsmasq to send a lifetime of 0 in the router advertisement > package. That way the clients know that this router shall not be used > any more. What? > Please confirm my findings that this is currently not possible with > dnsmasq. > > If so please accept my feature request to implement that. Patches to this mailinglist do get noticed. Groeten Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] HA Cluster - IPv6 router adv lifetime of 0
Hi, I've been trying to develop my own kind of firewall solution named nftwall which uses nftables as packet filter and is being managed centrally by Ansible - no webGUI. My first attempt was to use dnsmasq but then I found out of this obstacle. I've been thinking about switching to KEA + radvd but actually I would like to keep using dnsmasq. I manage my VRRP IPs with keepalived. There are small scripts for an event of a primary - secondary change. Especially in an event of controlled switch of primary - secondary I would like the primary dnsmasq to send a lifetime of 0 in the router advertisement package. That way the clients know that this router shall not be used any more. Please confirm my findings that this is currently not possible with dnsmasq. If so please accept my feature request to implement that. Regards Jochen Demmer ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Is it possible to merge host names on two Dnsmasq instances?
Hi Glen, On Wed, Sep 29, 2021 at 10:16:00AM +0800, Glen Huang wrote: > it seems impossible for the router to take over guest WiFi’s DHCP, > since it’s based on AP’s interfaces Just make the wired link between your router and the AP trunking, on the AP bridge main and guest SSIDs to different VLANs, and on the router serve all the VLANs with a single dnsmasq instance. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
