Bug 1773798

(In reply to Harald Jensås from comment #0)
> Description of problem:
> When an interface is configured for stateless DHCPv6 the client fail.
> 
> It looks like the /usr/sbin/dhclient-script does not execute, thus the
> PREINIT6 does not do the wait for link up. Since the link is no up the
> client fails.
dhclient is not supposed to wait for link to be up It's caller responsibility to call dhclient once link is up

(In reply to Pavel Zhukov from comment #2)
> (In reply to Harald Jensås from comment #0)
> > Description of problem:
> > When an interface is configured for stateless DHCPv6 the client fail.
> > 
> > It looks like the /usr/sbin/dhclient-script does not execute, thus the
> > PREINIT6 does not do the wait for link up. Since the link is no up the
> > client fails.
> dhclient is not supposed to wait for link to be up It's caller
> responsibility to call dhclient once link is up

Then why is there code in dhclient doing just that when dhcpclient is used without the "-S" (stateless) option?
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=blob;f=client/scripts/linux;h=0c42969744e4fd0ea513f9d5516183cef207c3b4;hb=HEAD#l410
 This code wait for link and duplicate address detection with a configurable timeout upstream. (Downstream this is static ...)


There is this KCS: https://kb.isc.org/docs/aa-01212 that explain that the interface must be up and the "link-local" address available. But at the same time afaict the default dhclient-script does implement the code to wait for exactly this?

This is an upstream bug https://bugs.isc.org/Public/Bug/Display.html?id=36169 that is marked as resolved, but it seem not to have solved the problem for "stateless" operation.

Since dhclient's default script does this for non stateless modes, it makes sense for it to do so for statelss as well?


If you still think this is'nt a dhclient issue, I guess we should change component to initscripts.

Thank you for posting links.

However most of them are related for statefull mode. As you mentioned dhclient does wait for link up in statefull mode but doesn't in stateless one. There is reason behind this. In stateless mode interface must be brought up and configured prior to dhclient asks for configuration otherwise it's possible to have race condition between RA and DHCP which may lead in wrong configuration (missed DNS/routers). It's out of scope of dhclient to do this kind of syncronization between RA and DHCP. That's why caller (initscripts, user (in case of manual calling of dhclient command, systemd, dracut or NetworkManager) must take care of it. 

You can check following links for more information (it's long story with applying and reverting patches):
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1101149#c3
[2] https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1764478

I hope this helps.

Thanks Pavel! I see in the launcpad link you posted why PREINIT6 cannot be used for stateless, this makes sense.

I can workaround the problem by adding "sleep 10" in /etc/sysconfig/network-scripts/ifup-eth

    357     # Initialize the dhclient args for IPv6 and obtain the hostname options if needed:
    358     DHCLIENTARGS="-6 -1 ${DHCPV6C_OPTIONS} ${DHCLIENTCONF} -lf ${LEASEFILE} -pf /var/run/dhclient6-${DEVICE}.pid ${DEVICE}"
    359     set_hostname_options DHCLIENTARGS
    360     sleep 10                                    # <-- Wait for IPv6 required when using '-S' option.
    361     if /sbin/dhclient $DHCLIENTARGS; then
    362         echo $" done."
    363     else


Component changed to initscripts. Version: initscripts-9.49.47-1.el7.x86_64

(In reply to Harald Jensås from comment #5)
> Thanks Pavel! I see in the launcpad link you posted why PREINIT6 cannot be
> used for stateless, this makes sense.
You're welcome!
P.S. There was PREINIT6S back in RHEL 6 but it was dropped due to reasons I mentioned.

Hi Harald,

I wasn't able to fully reproduce this issue in VM.

Could you please add option "rc.debug" on kernel cmd and send me output from journalctl?

Created attachment 1640046 [details]
journal with rc.debug on kernel commandline.

Hi Jan,

I reproduced the issue and attached the journalctl log with rc.debug enabled.


Regards
Harald

Hi Harald,

Thank you for log. It looks like it should work. There is function "ipv6_wait_tentative()" in initscripts which should avoid this issue. The problem might be, that device isn't available at the time of calling this function.

Could you please open file "/etc/sysconfig/network-sycipts/network-functions-ipv6". At the end of the file there is function "ipv6_wait_tentative()". Please add command "ip a" right before "while [ ${countdown} -gt 0 ]; do" and also inside while loop before "if [ -z $"ip_output" ]; then".

Then could you please send me log from journalctl again with "rc.debug" set on kernel cmd.

Thank you.
Jan

Created attachment 1650932 [details]
additional debug - 'ip a' commands added in "/etc/sysconfig/network-sycipts/network-functions-ipv6"

Hi Jan,

I reproduced the issue again with the 'ip a' commands added in "/etc/sysconfig/network-sycipts/network-functions-ipv6" as requested. See attached file.


Regards
Harald

Hi Harald,

The function "ipv6_wait_tentative()" which should to be waiting for DAD is waiting only for scope global addresses. Since this issue is related to scope link addresses, waiting for both scopes (link and global) should fix this issue.

Could you please make small modification inside "ipv6_wait_tentative()" function in "/etc/sysconfig/network-sycipts/network-functions-ipv6".

Please change ip command inside while loop to: 

   ip_output="$(ip -6 addr show dev ${device} tentative)"

and try to reproduce it with debug options set on kernel cmd. Then could you please send me log from journalctl.


Thank you.

Regards
Jan

Created attachment 1656020 [details]
journal with rc.debug - and "scope global" removed in ipv6_wait_tentative()

Hi Jan,

Looks like removing the scope global in ipv6_wait_tentative() fixes the issue.
See attached journal log.


Best Regards
Harald

Hi Harald,

Following patch should fix the issue. 

PR: https://github.com/fedora-sysv/initscripts/pull/309


Fix will be available in RHEL 7.9

Thank you very much for your cooperation.

Best Regards
Jan

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (initscripts bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3889