Re: Debugging prefix delegation: dhcpcd suddenly fails obtaining a prefix (but other devices/clients work)
Timo Sigurdsson
Sat Mar 13 00:18:58 2021Hi Roy, Roy Marples schrieb am 08.03.2021 11:04 (GMT +01:00): > Hi Timo > > On 07/03/2021 00:45, Timo Sigurdsson wrote: >> 5) I looked at the requests sent by dhcpcd and wide-dhcpv6-client with tcpdump >> to see if I can spot any differences: >> - wide-dhcpv6's clientid looks different (its form) than dhcpcd's. So I >> disabled the duid option in dhcpcd.conf and enabled clientid. Then their form >> looks the same, but that didn't solve the problem. >> - dhcpcd sends a vendor class option while wide-dhcpv6 doesn't. I couldn't >> find a way to disable sending this. I tried setting a different vendclass (I >> took the enterprise number of my ISP supplied device) but that didn't help >> either (and I also didnt really know what to put in the data field...). >> - dhcpcd sends options 82 and 83 that wide-dhcpv6 doesn't send. And it also >> has 'reconfigure accept' which wide-dhcpv6 doesn't. >> From the dumps the missing vendor class option with wide-dhcpv6 looked like >> the most meaningful, but as I said, I don't know how to disable sending it. > > You can try disabling options one at a time like so: > > # Don't send vendor class > nooption dhcp6_vivco > # Don't allow timer overrides > nooption dhcp6_sol_max_rt, dhcp6_inf_max_rt > # Don't allow reconfigure > nooption dhcp6_reconfigure_accept > > Find the option that's causing the problem and then complain to your ISP as > dhcpcd is to the best of my knowledge enitrely RFC compliant here. > It seems to me that only the first setting actually changes the request, i.e. the vendor option isn't sent anymore. The second setting actually results in an error "unknown option `sol_max_rt, dhcp6_inf_max_rt'". So, I assume the splitting on the comma doesn't work here. But even if I work around that by putting the two options on two seperate nooption lines (which makes the error message go away), tcpdump still shows both options being sent. Likewise for the last setting (nooption dhcp6_reconfigure_accept). It is still being sent. Actually, this was also my initial understanding of the nooption setting from reading the man page which says it will remove the option from the message before it's processed (which I read as, it's still being sent, but merely stripped from the reply so it doesn't get interpreted or processed by either dhcpcd or its hook scripts). Do you think a newer dhcpcd release might lead to other results? Then I'd spent more time building/packaging it. I did a short attempt to update the Debian package to the latest version and build it, but it failed and I haven'T looked into the specifics as to why that was, but if you think it might be worth a try, I'd spend a little more time on that. Thanks, Timo
Archive administrator: postmaster@marples.name