Do not set device runtime property on interfaces in the hotplug handler
and in fixup_interfaces(). This property conflicts with device option
in several proto handlers (mainly QMI and other WWAN/3G protos) and does
not seem to be used anywhere.
Signed-off-by: Ivan Shapovalov <intelfx@intelfx.name>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
Fixes the assumption the busybox udhcpc applet is always enabled; in case
the symbolic link check fails the DHCP shell handler script will exit and
as result the DHCP protocol handler will not be registered in netifd.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Support config in the form of ....
add_list sendopts=router:10.10.10.2
add_list sendopts=nissrv:20.20.20.2
add_list sendopts=0x7D:abba
This allows to configure sendopts having white spaces as option value
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
By default udhcpc asks for a default list of options; the config option
defaultreqopts allows to tweak this behavior.
When set to 0 udhcpc will not ask for any options except for the options
specified in the reqopts config option.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Certain DHCP servers push a gateway outside of the assigned interface subnet,
to support those situations, install a host route towards the gateway.
If Gateway and IP are served in same network, openwrt quagga cannot learn
routes (rip routes are not getting added, showing inactive) whereas
working fine when Gateway and IP are in different network.
Signed-off-by: Mogula Pranay <mogula.pranay@nxp.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
udhcpc doesn't send a hostname by default. Use the system hostname if
nothing else is specified, to always send a hostname.
It syncs the behaviour to odhcpc, which always sends a hostname.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Acked-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Hans Dedecker <dedeckeh@gmail.com>
Unmodified dns and domain variables could be needed in user script (/etc/udhcpc.user).
Signed-off-by: Tero Jänkä <tero.janka@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> (cleanup)
This option, defined by RFC3442, allows a DHCP server to send static
routes to a client. But the client has to request this option
explicitely.
Static routes are useful when the gateway configured by DHCP cannot be
in the same subnet as the client. This happens, for instance, when
using DHCP to hand out addresses in /32 subnets.
A new configuration option "classlessroute" is available, allowing
users to disable this feature (the option defaults to true).
Other DHCP clients already request this option by default (dhcpcd, for
instance, and possibly Windows). If a DHCP server does not support
this option, it will simply ignore it.
Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
Passing the hostname is currently broken in since the shipped busybox includes this commit:
https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?id=2017d48c0d70bef8768efb42909e605ea8eb5a21
Before:
Sun Jan 31 18:11:32 2016 daemon.notice netifd: Interface 'wan' is now down
Sun Jan 31 18:11:32 2016 daemon.notice netifd: Interface 'wan' is setting up now
Sun Jan 31 18:11:32 2016 daemon.notice netifd: wan (18158): udhcpc: option -h NAME is deprecated, use -x hostname:NAME
Sun Jan 31 18:11:32 2016 daemon.notice netifd: wan (18158): udhcpc: malformed hex string 'WR150'
After:
Sun Jan 31 18:11:33 2016 daemon.notice netifd: wan (18169): udhcpc (v1.23.2) started
Sun Jan 31 18:11:33 2016 daemon.notice netifd: wan (18169): Sending discover...
Sun Jan 31 18:11:33 2016 daemon.notice netifd: wan (18169): Sending select for xxx.yyy.zzz.xyz...
Sun Jan 31 18:11:33 2016 daemon.notice netifd: wan (18169): Lease of xxx.yyy.zzz.xyz obtained, lease time 600
Signed-off-by: Merlijn Wajer <merlijn@wizzup.org>
Remove the udhcpc -R release option as sending a DHCP release
is configurable via the uci option release.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Make sending a DHCP release configurable when the client exits allowing to clean up
IP/mac state info in intermediate devices.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Let DHCP client send a release when it exists so the DHCP server is
informed the IP address is released and allowing to clean up IP/mac
state info in intermediate devices.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
hand over parameters to user-script e.g. $1=deconfig
Signed-off-by: Leon George <leon@georgemail.de>
Signed-off-by: Christian Mehlis <christian@m3hlis.de>
SVN-Revision: 45626
Certain DHCP servers push a gateway outside of the assigned interface subnet,
to support those situations install a host route towards the gateway.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 44789
Extend the DHCPv4 handler script to store additional information from the
DHCP lease in the per-interface data object.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
SVN-Revision: 44092
Commit ce92f6650bd8a86db04c7a6cbb58e7fdb200a7e6 added source IP support
for DHCP default routes. As a side effect of this change the default route
could be present twice in netifd (once with source IP set and once with
source IP unset) if it was sent by the server in both the router and static
route options. Therefore add source IP support as well for static routes as this
case was not considered. Additional remove unused parameter type.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 43645
I have not found a scenario that would break by setting the source address on
default, but please let me know if any special considerations should be taken.
Signed-off-by: Kristian Evensen <kristian.evensen at gmail.com>
SVN-Revision: 43582
Patch allows to configure the mtu of the dynamic 6rd tunnel interface when created by dhcp script.
In some setups it's desirable to have config control over the 6rd tunnel mtu to maximize the traffic throughput
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
SVN-Revision: 42871
This was done previously when dhcp was handled by the network scripts.
So netifd should behave the same.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
SVN-Revision: 34704
