/etc/ethers is missing on /rom but always created when dnsmasq
runs. It is better to have it in place and avoid an extra change
in flash after firstboot.
It will generate an extra /etc/ethers-opkg when it has changed.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Restarting service sysctl echos multiple errors like:
sysctl: -e: No such file or directory
After the first filename, all remaining arguments are treated
as files.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Update the link to the current section in the documentaion wiki.
This fixes https://github.com/openwrt/packages/issues/6282
Signed-off-by: Sven Roederer <freifunk@it-solutions.geroedel.de>
There is no usecase for not protecting symlinks that I know of in OpenWrt.
Not even on desktop systems where you have multiple users with a shell.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Our commands setting accept_ra to 0 on all interfaces got lost in the
transition to procd. This remained unnoticed for a long time, as we also
enable forwarding on all interfaces, which prevents RA handling by default.
Restore the commands, while also fixing a possible race condition in the
old version.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
We can use /etc/sysctl.d/* for package-supplied sysctl snippets, giving
admins the option to use /etc/sysctl.conf to override settings.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
11_migrate-sysctl has not been updated with new file hashes since 2012.
Let's get rid of it.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
The default fragment low/high thresholds are 3 and 4 MB. On devices with
only 32MB RAM, these settings may lead to OOM when many fragments that
cannot be reassembled are received. Decrease fragment low/high thresholds
to 384 and 512 kB on devices with less than 64 MB RAM.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
There was a mismatch between indicating factory reset and code actually
starting it. After 5 seconds status LED started blinking rapidly letting
user know it's ready to release reset button. In practice button had to
stay pressed for another second in order to relly start the process.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Obviously not all GPIO controller allow to change the direction. The issue
is around since the beginning of the script but only due to the recent
changes error messages are more visible.
Add a check if a change of the direction is supported by the GPIO
controller and fallback to setting only the value if not.
Fixes: FS#1271
Signed-off-by: Mathias Kresin <dev@kresin.me>
GPIOs are exported as active high to the sysfs, hence the logic need to be
inverted.
Fixes: e66c47fb14 ("base-files: gpio switch: set output value with
direction")
Signed-off-by: Mathias Kresin <dev@kresin.me>
Use the "low" and "high" values to configure the GPIO as an output with
that initial value. It ensures that the gpio doesn't have a unwanted value
during the time the direction is set to ouput and the actual value is
applied.
We don't need to take care of the GPIO polarity for now, since our
exported GPIOs are always active low.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Start gpio_switch before the boot state is set to up/initialised/done.
This way the exported GPIOs are available at the time rc.local is started.
Signed-off-by: Mathias Kresin <dev@kresin.me>
In current state, if there is START but no STOP, enbale()
will return 1 (failure), which is wrong.
Moreover there is no need to check for START/STOP twice.
Instead, add err variable to save success state and
and return it's value.
Also eliminate the need to disable() by using 'ln -sf',
which will first delete the old symlink if one exists.
Changes from v1:
- fixed description
Signed-off-by: Roman Yeryomin <roman@advem.lv>
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Fixes: 8170f280c4 ("base-files: set FAILSAFE in /etc/profile when
/tmp/.failsafe exists")
Since dropbear clears the environment, FAILSAFE was not set as intended in
failsafe mode. This also broke sysupgrade from failsafe mode over SSH.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
- use %d instead of %n for opkg feed identifiers
- remove %n / %N references from version files
Fixes bf5cef47b3 merge: release/banner: drop release name and update banner.
Fixes FS#1213.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Set sysctl fs.suid_dumpable = 2
This allows suid processes to dump core according to kernel.core_pattern
setting. LEDE typically uses suid to drop root priviledge rather than
gain it but without this setting any suid process would be unable to
produce coredumps (e.g. dnsmasq)
Processes still need to set a non zero core file process limit ('ulimit
-c unlimited' or if procd used 'procd_set_param limits
core="unlimited"') in order to produce a core. This setting removes an
obscure stumbling block along the way.
>From https://www.kernel.org/doc/Documentation/sysctl/fs.txt
suid_dumpable:
This value can be used to query and set the core dump mode for setuid
or otherwise protected/tainted binaries. The modes are
0 - (default) - traditional behaviour. Any process which has changed
privilege levels or is execute only will not be dumped.
1 - (debug) - all processes dump core when possible. The core dump is
owned by the current user and no security is applied. This is
intended for system debugging situations only. Ptrace is unchecked.
This is insecure as it allows regular users to examine the memory
contents of privileged processes.
2 - (suidsafe) - any binary which normally would not be dumped is dumped
anyway, but only if the "core_pattern" kernel sysctl is set to
either a pipe handler or a fully qualified path. (For more details
on this limitation, see CVE-2006-2451.) This mode is appropriate
when administrators are attempting to debug problems in a normal
environment, and either have a core dump pipe handler that knows
to treat privileged core dumps with care, or specific directory
defined for catching core dumps. If a core dump happens without
a pipe handler or fully qualifid path, a message will be emitted
to syslog warning about the lack of a correct setting.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com> [PKG_RELEASE increase]
This is needed for an upcoming change to the hotplug default rules which
will cause /dev/tty* nodes to get assigned to the "tty" group in order
to support unprivileged user access when needed.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Bug introduced with 6713694.
I did not count on procd handling reload as mentioned
in this doc:
https://wiki.openwrt.org/inbox/procd-init-scripts
```
procd_set_param file /var/etc/your_service.conf # /etc/init.d/your_service reload will restart the daemon if these files have changed
procd_set_param netdev dev # likewise, except if dev's ifindex changes.
procd_set_param data name=value ... # likewise, except if this data changes.
```
The service would be restarted regardless of any of those params.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This was also working before, with a slightly
different semantic.
[ Original semantic ]
If no reload hooks was implemented, the default one would
kick in, it would return fail, and restart would happen.
This would happen also in the case where a reload hook
would be implemented, it would fail, and it would restart
the service.
[ New semantic ]
The default reload hook calls restart.
Services can implement their own reload.
If reload fails, then the '/etc/init.d/<service> reload'
would return a non-zero code, and the caller can choose
a way to handle this.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
If only a single opkg control file exists (which can happen with
CONFIG_CLEAN_IPKG), grep would not print the file name by default. Instead
of forcing it using -H, we just switch to -l (print only file names) and
get rid of the cut.
Add -s to suppress an error message when no control files exist.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Knowing the package architecture at runtime can be useful, e.g. to
configure opkg repository URLs. The value of ARCH_PACKAGES ("%A" in
VERSION_SED) as added to openwrt_release (as DISTRIB_ARCH) and os-release
(as LEDE_ARCH).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
currently (after blogic's edit to my commit) it prints like this:
root@lede:/# service aa
aa does not exist. the following services are available :adblock dnsmasq gpio_switch rpcd system
boot done led sqm uhttpd
crelay dropbear log sysctl umount
cron firewall network sysfixtime urandom_seed
ddns fstab odhcpd sysntpd
which looks pretty bad, and is even worse if someone writes only "service" without arguments, as it will print " does not exist. " which is confusing.
with this commit it looks like this:
root@lede:/# service
service "" not found, the following services are available:
adblock dnsmasq gpio_switch rpcd system
boot done led sqm uhttpd
crelay dropbear log sysctl umount
cron firewall network sysfixtime urandom_seed
ddns fstab odhcpd sysntpd
Yes there is some play with " and ', it is to display "name" or just "" if no service name is entered (like in the example).
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
Move the revision info to the VERSION_CODE variable and default VERSION_NUMBER
to CURRENT for master branch builds.
Also introduce a new menuconfig option CONFIG_VERSION_CODE which allows users
to override the revision value put into VERSION_CODE and adjust the template
files used by the base-files package to accomodate for the changed semantics.
While we're at it, also adjust the various URLs to match the current web site.
After this commit, the relevent files will look like the examples given below:
# cat /etc/openwrt_version
r2398+1
# cat /etc/openwrt_release
DISTRIB_ID='LEDE'
DISTRIB_RELEASE='CURRENT'
DISTRIB_REVISION='r2398+1'
DISTRIB_CODENAME='reboot'
DISTRIB_TARGET='x86/64'
DISTRIB_DESCRIPTION='LEDE Reboot CURRENT r2398+1'
DISTRIB_TAINTS='no-all override'
# cat /usr/lib/os-release
NAME="LEDE"
VERSION="CURRENT, Reboot"
ID="lede"
ID_LIKE="lede openwrt"
PRETTY_NAME="LEDE Reboot CURRENT"
VERSION_ID="current"
HOME_URL="http://lede-project.org/"
BUG_URL="http://bugs.lede-project.org/"
SUPPORT_URL="http://forum.lede-project.org/"
BUILD_ID="r2398+1"
LEDE_BOARD="x86/64"
LEDE_TAINTS="no-all override"
LEDE_DEVICE_MANUFACTURER="LEDE"
LEDE_DEVICE_MANUFACTURER_URL="http://lede-project.org/"
LEDE_DEVICE_PRODUCT="Generic"
LEDE_DEVICE_REVISION="v0"
LEDE_RELEASE="LEDE Reboot CURRENT r2398+1"
On a release branch, those files would look like:
# cat /etc/openwrt_version
r2399
# cat /etc/openwrt_release
DISTRIB_ID='LEDE'
DISTRIB_RELEASE='16.12-CURRENT'
DISTRIB_REVISION='r2399'
DISTRIB_CODENAME='test_release'
DISTRIB_TARGET='x86/64'
DISTRIB_DESCRIPTION='LEDE Test Release 16.12-CURRENT r2399'
DISTRIB_TAINTS='no-all override'
# cat /usr/lib/os-release
NAME="LEDE"
VERSION="16.12-CURRENT, Test Release"
ID="lede"
ID_LIKE="lede openwrt"
PRETTY_NAME="LEDE Test Release 16.12-CURRENT"
VERSION_ID="16.12-current"
HOME_URL="http://lede-project.org/"
BUG_URL="http://bugs.lede-project.org/"
SUPPORT_URL="http://forum.lede-project.org/"
BUILD_ID="r2399"
LEDE_BOARD="x86/64"
LEDE_TAINTS="no-all override"
LEDE_DEVICE_MANUFACTURER="LEDE"
LEDE_DEVICE_MANUFACTURER_URL="http://lede-project.org/"
LEDE_DEVICE_PRODUCT="Generic"
LEDE_DEVICE_REVISION="v0"
LEDE_RELEASE="LEDE Test Release 16.12-CURRENT r2399"
On a release tag, those files would look like:
# cat /etc/openwrt_version
r2500
# cat /etc/openwrt_release
DISTRIB_ID='LEDE'
DISTRIB_RELEASE='17.02.1'
DISTRIB_REVISION='r2500'
DISTRIB_CODENAME='mighty_unicorn'
DISTRIB_TARGET='x86/64'
DISTRIB_DESCRIPTION='LEDE Mighty Unicorn 17.02.1 r2500'
DISTRIB_TAINTS='no-all override'
# cat /usr/lib/os-release
NAME="LEDE"
VERSION="17.02.1, Mighty Unicorn"
ID="lede"
ID_LIKE="lede openwrt"
PRETTY_NAME="LEDE Mighty Unicorn 17.02.1"
VERSION_ID="17.02.1"
HOME_URL="http://lede-project.org/"
BUG_URL="http://bugs.lede-project.org/"
SUPPORT_URL="http://forum.lede-project.org/"
BUILD_ID="r2500"
LEDE_BOARD="x86/64"
LEDE_TAINTS="no-all override"
LEDE_DEVICE_MANUFACTURER="LEDE"
LEDE_DEVICE_MANUFACTURER_URL="http://lede-project.org/"
LEDE_DEVICE_PRODUCT="Generic"
LEDE_DEVICE_REVISION="v0"
LEDE_RELEASE="LEDE Mighty Unicorn 17.02.1 r2500"
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Acked-by: Felix Fietkau <nbd@nbd.name>
"service" is a simple wrapper that will allow to call init.d scripts
current method: # /etc/init.d/network reload
with the wrapper: # service network reload
If the wrapper is called without arguments or with a wrong init script name, it will print an error and list the content of /etc/init.d/ folder
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
A firmware compiled with BUSYBOX_CONFIG_ARP should also use by default the
arp binary from busybox. Otherwise the extra functionality the user
requested can only be used when running arp with the path to the binary.
Signed-off-by: Marek Lindner <marek.lindner@open-mesh.com>
Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
Currently, the wifi detection script is executed as part of
the (early) boot process. Pluggable wifi USB devices, which
are inserted at a later time are not automatically
detected and therefore they don't show up in LuCI.
A user has to deal with wifi detection manually, or restart
the router.
However, the current "sleep 1" window - which the boot
process waits for wifi devices to "settle down" - is too
short to detect wifi devices for some routers anyway.
For example, this can happen with USB WLAN devices on the
WNDR4700. This is because the usb controller needs to load
its firmware from UBI and initialize, before it can operate.
The issue can be seen on a BT HomeHub 5A as well as soon as
the caldata are on an ubi volume. This is because the ath9k
card has to be initialized by owl-loader first. Which has to
wait for the firmware extraction script to retrieve the pci
initialization values inside the caldata.
This patch moves the wifi configuration to hotplug scripts.
For mac80211, the wifi configuration will now automatically
run any time a "ieee80211" device is added. Likewise
broadcom-wl's script checks for new "net" devices which
have the "wl$NUMBER" moniker.
Issues with spawning multiple interface configuration - in
case the detection script is run concurrently - have been
resolved by using a named section for the initial
configuration. Concurrent configuration scripts will now
simply overwrite the same existing configuration.
A workaround which preserves the "sleep 1" window for just
the first boot has been added. This allows the existing
brcm47xx boot and mvebu uci-default scripts to correctly
setup the initial mac addresses and regulatory domain.
And finally, the patch renames the "wifi detect" into
"wifi config". As the script no longer produces any output
that has to be redirected or appended to the configuration
file.
Thanks to Martin Blumenstingl for helping with the implementation
and testing of the patch.
Acked-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Previously, wifi detect simply dumped its generated wireless
configuration to STDOUT. A second step was needed to append
the configuration to /etc/config/wireless (or create it, if
it didn't exist).
With this patch, The wifi detection script will now use uci
to update the wireless configuration directly.
This patch also makes the initially created wifi-iface a
named section ('default_radio$X' for mac80211 and
'default_wl$X' for broadcom). With this change, uci will
not print the cfgHASH to STDOUT (which would now corrupt
the wireless configuration). It will also prevent adding
duplicated wifi interface configurations, if the wifi
configuration is run concurrently.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
We need to tell hwclock with -u commandline option, that we would like
to keep our RTC clock in UTC timezone. Linux kernel expects RTC in UTC
timezone anyway.
In current state of things, we don't tell hwclock to load/store time
from/to RTC in UTC timezone so it uses the timezone from the system
time. If it's set to different timezone then UTC, sysfixtime is going to
screw the time in RTC.
I've following in the setup script:
uci set system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3'
uci set system.@system[0].zonename='Europe/Prague'
I've this RTC setup (rtc1 is RTC on i.MX6 SoC, rtc0 is battery backed RTC mcp7941x):
rtc-ds1307 3-006f: rtc core: registered mcp7941x as rtc0
snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-r as rtc1
Then we can experience following (current time is 10:15am):
$ date
Fri Oct 21 10:15:07 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:14:46 2016 0.000000 seconds
$ hwclock -u -r -f /dev/rtc0
Fri Oct 21 10:14:46 2016 0.000000 seconds
And after current broken sysfixtime:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:25 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 10:15:31 2016 0.000000 seconds
Now we've time in our battery backed RTC in CEST timezone instead of
UTC. Then once again, but with this patch applied to sysfixtime, where
hwclock is using correctly the -u parameter:
$ /etc/init.d/sysfixtime stop
$ date
Fri Oct 21 10:15:53 CEST 2016
$ hwclock -r -f /dev/rtc0
Fri Oct 21 08:15:55 2016 0.000000 seconds
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Acked-by: Jo-Philipp Wich <jo@mein.io>
Currently the reset script will try to run jffs2reset on boards that are
running a rw rootfs, such as ext4. This will cause jffs2reset to fail
and the board to never reboot while the LED blinks until a manual
reboot.
This commit does two different things:
1. Disables reset on boards that do not have an overlay mount
2. Disables the Blinking LED after 5 seconds if the board does not
support reset
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
This helper allows using usbport trigger directly. It requires usbport
compatible syntax and supports specifying multiple USB ports, e.g.:
ucidef_set_led_usbport "usb" "USB" "devicename:colour:function" "usb1-port1" "usb2-port1"
This adds a proper object to the board.json, e.g.
"usb": {
"name": "USB",
"type": "usbport",
"sysfs": "devicename:colour:function",
"ports": [
"usb1-port1",
"usb2-port1"
]
}
and supports translating it into uci section.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This makes init.d script handle existing UCI entries using the new
trigger. It also switches all targets to use its package.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Now that we know that the password is in /etc/shadow and not in
/etc/passwd, we can properly fix the logic for the empty password check.
Only 'root::' is an empty password, 'root❌' and 'root:!:' allow no
password login at all.
This fixes the empty password warning still showing after the root password
has been locked using 'passwd -l root' (e.g. to allow public-key auth
only).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Local variable declarations outside of functions are illegal since the Busybox
update to v1.25.0, therfore remove them from the appropriate places.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
oneshot trigger configurations for LEDs are created, but the on/off
timing configurations are ignored. generate_config is correctly creating
oneshot configs, but the later led script doesn't recognise the trigger
details.
Fixes: c0c3f2d4c9 leds: support oneshot as well as timer triggers
Signed-off-by: Karl Palsson <karlp@etactica.com>
Instead of board_detect generating the config as a side effect, let
config_generate call board_detect as needed.
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
The pi_* variables and the fs_failsafe_wait_timeout variable are set by
the CONFIG_TARGET_PREINIT_* config options. No need to maintain the same
values twice.
All other fs_ variables were never used.
Signed-off-by: Mathias Kresin <dev@kresin.me>
