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

Cheers,
Petr

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@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: pemen...@redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-- 
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

Reply via email to