[Dnsmasq-discuss] [PATCH] DHCPv6 - network booting 'address in use'

Petr Menšík pemensik at redhat.com
Tue Oct 12 01:54:28 UTC 2021

Could I make a point to this change those changes again for a
recorsideration, please?


On 9/22/21 16:33, Petr Menšík wrote:
> I made error in patch2. Fixed it and added patch3, adding support for
> client-arch also for IPv6.
> I have used following configuration for dnsmasq on libvirt network:
> log-dhcp
> port=0
> interface=host0
> dhcp-sequential-ip
> dhcp-range=::,static
> dhcp-match=ipxe,175
> # dhcpv6s for Client System Architecture Type (61)
> dhcp-match=set:efi6,option6:61,0007
> dhcp-match=set:efi6,option6:61,0009
> dhcp-match=set:efi6,option6:61,0011
> dhcp-userclass=set:ipxe6,iPXE
> dhcp-vendorclass=set:efi6,PXEClient
> # Client is PXE booting over EFI without iPXE ROM; send EFI version of iPXE chainloader
> dhcp-option=tag:efi6,tag:!ipxe6,option6:bootfile-url,tftp://[2620:dead:beef:4::1]/shimx64.efi
> enable-tftp
> tftp-root=/tftproot # use /var/lib/tftproot as alternative, tftp-server package
> # Use static allocated only, replace with MAC of your client VM
> dhcp-host=52:54:00:06:57:c3,tag:dhcpv6,netboot.test,[2620:dead:beef:4::d1],[2620:dead:beef:4::d2],[2620:dead:beef:4::d3],120
> It requires radvd running on the the same host, because I think dnsmasq itself cannot provide this combination.
> Interface has to broadcast those flags: AdvSendAdvert on; AdvManagedFlag on;
> Now create a new VM using libvirt (virt-manager), no disk image.
> I used EFI bios, but I expect any TianoCore firmware powered machine would
> behave the same. Leave IPv4 booting not working, it is tried first. Then IPv6 is tried.
> In combination with radvd, it would require two addresses.
> One for plain IP address, the second for obtaining also boot url and parameters.
> Depending on their order, it may boot even without a change. Sometimes.
> It should boot always after those patches, increasing reliability of DHCP assignments.
> Cheers,
> Petr
> On 9/20/21 11:55, Harald Jensas wrote:
>> On 9/17/21 21:16, Petr Menšík wrote:
>>> Hi Harald, Simon,
>>> I made an alternative change, which I think has similar output. I
>>> think the use of DHCP6UNSPEC is suspicious itself and does not have
>>> any good error code assigned by RFC 8415, because it should not
>>> result in an error. I have tried to add also MUST require from the
>>> RFC, refusing off-link requests with NotOnLink error. Not yet tested
>>> it myself, I have no IPv6 booting environment available (yet). That
>>> is in patch1.
>>> Patch2 is just bunch of const changes, reduction of repeated status
>>> code filling into dedicated function. Should not change behaviour,
>>> just reduces few lines and some cosmetic changes.
>> Thanks Petr!
>> I did a couple of IPv6 network boot tests using your patches and can
>> confirm that it works as expected.
>> -- 
>> Harald
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211012/fa06662b/attachment-0001.htm>

More information about the Dnsmasq-discuss mailing list