RFC3442 specifies a DHCP extension to provide the client with a list of
static routes to use. This is already handled by udhcpc and exposed as the
"staticroutes" environment variable, but currently not handled by the action
script.
Extend the script to do so. The RFC specifies that if this option is
provided by the server then the normal "routes" (3) option should be
ignored, so ensure that is done.
As we may now have more than just a default route on the interface, extend
the route cleanup logic to handle all routes for the interface (except for
the implied local 0.0.0.0 one).
Notice that this option is only sent by servers if explicitly requested by
the client, E.G. using the -O staticroutes option to udhcpc.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When using a combination of udhcpc and avahi-autoipd in case of receiving IP
from a DHCP server, the following message can be seen:
"Failed to kill daemon: No such file or directory".
Add a check for a running avahi-autoipd to fix this issue.
Signed-off-by: Lukasz Tekieli <tekieli.lukasz@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
udhcpc6 implements "stateful" DHCPv6 for explicitly requesting an address
and other configuration information. A major difference between DHCPv4
and DHCPv6 is that DHCPv6 does *not* advertise a default route; this is
determined by normal IPv6 autoconfiguration.
Add logic to wait up to IF_WAIT_DELAY seconds for the IPv6 route to be
configured; as above this doesn't come from DHCPv6 but rather the IPv6
Router Advertisement (RA) which happens independently from udhcpc6. The
intent here is to try and ensure that the interface is route-able upon the
script's completion as it would be if called from udhcpc.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
udhcpc6 will call the default script with the stateful address set in the
"ipv6" variable. Set "ip" to this address if present, using the /128 prefix
used by stateful DHCPv6 so the existing renew/bound logic can be used like
in DHCPv4.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The domain search option is from RFC3397, not RFC3359 (which is about TLV
codepoints), so fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* package/busybox/udhcpc.script: Use $search instead of $domain if
that is defined.
Note that for this to work, not only has CONFIG_FEATURE_UDHCP_RFC3397
be enabled in Busybox' configuration but also the option has to be
requested using the "-O search" command-line option (one can set it in
CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS, for instance).
[Peter: add comment with reference to rfc3359/option 119 for clarity]
Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The (u)dhcpc hook installed by the busybox package configures the
network and exits. If we want to do anything further with a DHCP lease,
we'd have to replace the script entirely.
This change introduces a .d directory for hooks (based on the script
filename), which are executed after the interface configuration. This
allows packages to drop a script file in the .d directory to perform
actions on DHCP events.
We'll use this in a later change to notify petitboot of DHCP boot
information.
[Thomas: update to latest Buildroot, fix indentation.]
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Suppress the following error:
route: SIOCDELRT: No such process
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Eliminate the following error message on every boot:
grep: /etc/resolv.conf: No such file or directory
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When udhcpc is used on multiple network devices at the same time (or a mix
of dhcp and fixed configuration), /etc/resolv.conf should contain the
union of information from all the interfaces.
Currently that's not the case. The udhcpc script simply overwrites
resolv.conf with the information from the specific interface on each dhcp
bound/renew event.
Fix it by tagging lines with the interface they came from when added,
and drop the affected lines on deconfig/renew. As /etc/resolv.conf is
often a symlink to /tmp (and rootfs might be read only), special care
has to be taken when it is updated.
Notice that I'm not really aware of any official documentation requiring
that '#' comments in /etc/resolv.conf must be supported, but atleast
glibc and uClibc do.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
ifconfig up is a no-op if the device is already running, so let's just
do that unconditionally.
Systems might have multiple network devices, and perhaps run udhcpc on
another interface even when booted over nfs, so don't disable the
per-interface deconfig based on the global nfsroot= setting on the kernel
command line.
If you don't want udhcpc to mess with kernel level IP autoconfiguration
(E.G. for nfs boot), you should instead ensure udhcpc/ifup/ifplugd isn't
started for that interface.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We're currently using two different udhcpc scripts, one in the busybox
package and another in the avahi one, which calls avahi-autoipd on
dhcp failures.
The avahi one actually only does something differently from the default
if avahi-autoipd is available, so let's just always use this one instead
of the complicated logic about writing the file if not present /
overwriting it afterwards.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since udhcpc is part of busybox, it seems logical to move the udhcpc
script from skeleton to busybox.
[Peter: only install if not available in skeleton]
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
