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
Since the switch to netifd, proto handlers may always set the defaultroute
and provide dns server addresses, netifd will decide in the generic code
path whether the announced values are masked or not.
Additionally protocol handlers should not modify the routing tables themselves
and prevent any launched services from doing so.
Remove the additional defaultroute and peerdns option handling from the ppp.sh
protocol handler and rely on netifd to mask or not mask the values.
SVN-Revision: 34536
Upstream has a few code cleanups, more eagerly burns sensitive memory and
includes the fix for CVE-2012-0920. Full changelog:
https://matt.ucc.asn.au/dropbear/CHANGES
Local changes:
- Removed PKG_MULTI which is no longer in options.h (even before 2011.54)
- Merged DO_HOST_LOOKUP into 120-openwrt_options.patch
- Removed LD from make opts (now included in TARGET_CONFIGURE_OPTS)
- Removed 400-CVE-2012-0920.patch which is included in 2012.55
Signed-off-by: Catalin Patulea <cat@vv.carleton.ca>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 34496
- use comment match to keep track of per-network rules
- setup reflection for any interface which is part of a masqueraded zone, not just "wan"
- delete per-network reflection rules if network is brought down
SVN-Revision: 34472
Previously only the first macfilter configuration would have been used
on all interfaces. However, the configuration was always done per vif
already. Hence, move the macfilter setup into hostapd.sh where and
create one mac list file per vif.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
SVN-Revision: 34470
In particular, it wants to run before the ntpclient script. Which may
block for a long time attempting to do DNS lookups for NTP servers. In
my case, that would have *worked* if the new device had been added to
teql first, rather than timing out.
This was effectively causing a huge delay between an interface coming
up, and routing actually starting to work.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 34442
6relayd is an IPv6-tool that relays IPv6-management protocols like router
discovery, neighbor discovery and DHCPv6 so that clients on routed
(non-bridged) interfaces can use the public address prefix, DHCPv6 and
DNS-service of a master interface. This is useful to avoid NAT in chained
IPv6-routers.
SVN-Revision: 34008
