<div dir="ltr"><div><br></div><div>Hello!</div><div><br></div><div>Thank you for all your help, and sorry for the delay in my response.</div><div>I have conducted tests based on the opinions of <a class="gmail_plusreply" id="plusReplyChip-0">@pemensik</a> and @imnozi, but unfortunately, the same issue continues to occur. </div><div><br></div><div>From <a class="gmail_plusreply" id="plusReplyChip-1">@imnozi
suggestions :</a></div><div> - An easy-ish thing to check in the source: </div><div> is the counter wide enough(16-, 32- or 64-bits)?</div><div> A: I think the issue might not be related to bits specifically. However, I have noticed that there are differences in how the lease_max value is checked between DHCPv6 and DHCPv4 in the code.</div><div> - What happens when the max is set to 4, 16, etc.? </div><div> A: I've changed the value to 4, and the result seems the same.<br> o Is there a maximum before the limit fails to limit?</div><div> A: No, it seems not.<br> o Does it always assign max+1 leases?</div><div> A: it does not fail at max+1, DHCPv6 server provides more than that.<br><br></div><div>From @pemensik suggestions:</div><div> I modified the script to use "-D LLT" for the client in order to obtain a time-sensitive value in the DUID (Client Identifier), and also remove the lease info file (/var/lib/dhcp/*) for each time.</div><div><br></div><div><br></div><div>I am attaching the pcap file and scripts here for reference, the pcap file is based on the value of DHCP max lease is "4".<br></div><div>Please kindly let me know if I'm doing wrong for doing this.</div><div><br></div><div>Thanks,</div><div>Lin</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Petr Menšík <<a href="mailto:pemensik@redhat.com" target="_blank">pemensik@redhat.com</a>> 於 2023年5月26日 週五 上午7:45寫道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes, dhclient generates DUID into its lease file. Either add -lf <br>
/var/lib/dhclient/dhclient-$I.leases or just remove lease file after <br>
each dhclient run. Parameter -D LLT might help too.<br>
<br>
It should be visible what IPv6 address it is offering to the client in <br>
logs. Does it change?<br>
<br>
Petr<br>
<br>
On 5/23/23 10:11, Simon Kelley wrote:<br>
> In DHCPv6, the unique identifier for a client is NOT the MAC address, <br>
> it's a client ID which sometimes contains the MAC address.<br>
><br>
> I suspect that dhclient is using the exact same client-id for each <br>
> trial, and just renewing the existing lease. You will need to delete <br>
> all the dhclient state after killing the process.<br>
><br>
> Simon.<br>
><br>
><br>
> On 23/05/2023 08:43, Linyih Teng wrote:<br>
>> For the test.. i'm just curious, there is no other reason.<br>
>><br>
>> However, On the client side, I wrote simple scripts to run the <br>
>> dhclient, and this script will sequentially run 512 dhclient.(the <br>
>> number 512 is not a magic value, other values will happen same <br>
>> situation.)<br>
>><br>
>> steps of the script:<br>
>><br>
>> 1. create macvlan interface(It will make different MAC address for<br>
>> clients)<br>
>><br>
>> 2. run dhclient with macvlan interface<br>
>><br>
>> 3. get an IP from DHCPv6 server<br>
>><br>
>> 4. kill the dhclient and remove the macvlan interface<br>
>><br>
>> 5. back to step 1. and go on.<br>
>><br>
>><br>
>> Results:<br>
>><br>
>> After scripts, if the 513th client comes, the server will serve the<br>
>> IP to the 513th client. but it is not just lease max + 1 th client<br>
>> getting this issue, all after the 512th client can get IP from the<br>
>> server.<br>
>> At this time, the lease entries are remaining at 512, and all after<br>
>> clients will not appear in the lease file.<br>
>><br>
>><br>
>><br>
>> Thanks,<br>
>> Lin<br>
>><br>
>><br>
>><br>
>> Geert Stappers <<a href="mailto:stappers@stappers.nl" target="_blank">stappers@stappers.nl</a> <mailto:<a href="mailto:stappers@stappers.nl" target="_blank">stappers@stappers.nl</a>>> 於 <br>
>> 2023年5月23日 週二 下午1:59寫道：<br>
>><br>
>> On Tue, May 23, 2023 at 12:05:08AM +0100, Simon Kelley wrote:<br>
>> > On 22/05/2023 12:18, Linyih Teng wrote:<br>
>> > > In the manual page is written:<br>
>> > > > -X, --dhcp-lease-max=<number><br>
>> > > > Limits dnsmasq to the specified maximum number of<br>
>> DHCP<br>
>> > > > leases. The default is 1000. This limit is to <br>
>> prevent DoS<br>
>> > > > attacks from hosts which create thousands of leases<br>
>> and use<br>
>> > > > lots of memory in the dnsmasq process.<br>
>> > ><br>
>> > > Hello,<br>
>> > ><br>
>> > > I'm using dnsmasq2.89 and testing the maximum lease count of<br>
>> the DHCPv6<br>
>> > > server with the *dhcp-lease-max* option.<br>
>> > ><br>
>> > > For the testing, I'm using below configuration:<br>
>> > ><br>
>> > > *dhcp-lease-max* = 512<br>
>> > > *dhcp-range*=tag:pool0,2022::1,2022::1f:ffff:ffff:fffe,64,120m<br>
>> > > tag-if=set:pool0,tag:intfv0<br>
>> > ><br>
>> > ><br>
>> > > However, when the number of clients reaches the maximum <br>
>> number, the<br>
>> > > server still provides IPs to clients. Is this the expected<br>
>> behavior of<br>
>> > > DHCPv6?<br>
>> > ><br>
>> > There's a possible difference between the number of clients and<br>
>> the number<br>
>> > of DHCP leases, since leases can expire to be deleted by the <br>
>> client.<br>
>> ><br>
>> > Are you saying that the number of simultaneous DHCP leases<br>
>> increases without<br>
>> > bound, or that the 513th client gets a lease? Have you checked<br>
>> the number of<br>
>> > leases in the dnsmasq.leases file?<br>
>><br>
>> Original Poster has yet to say what the expected behaviour should <br>
>> be.<br>
>><br>
>> Thing I am saying: Why limit dhcp-range by dhcp-lease-max?<br>
>><br>
>><br>
>> Regards<br>
>> Geert Stappers<br>
>> -- Silence is hard to parse<br>
>><br>
>> _______________________________________________<br>
>> Dnsmasq-discuss mailing list<br>
>> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
>> <mailto:<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a>><br>
>> <a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a> <br>
>> <<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>> <br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Dnsmasq-discuss mailing list<br>
>> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
>> <a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
><br>
> _______________________________________________<br>
> Dnsmasq-discuss mailing list<br>
> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
<br>
-- <br>
Petr Menšík<br>
Software Engineer, RHEL<br>
Red Hat, <a href="https://www.redhat.com/" rel="noreferrer" target="_blank">https://www.redhat.com/</a><br>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB<br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div></div>