openwrt issueshttps://code.fe80.eu/openwrt/openwrt/-/issues2019-09-10T10:46:51Zhttps://code.fe80.eu/openwrt/openwrt/-/issues/2418Build failure - Netgear 6220 (mt7621)2019-09-10T10:46:51ZaparcarBuild failure - Netgear 6220 (mt7621)Username: Kamil Darczynski
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2418Username: Kamil Darczynski
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2418https://code.fe80.eu/openwrt/openwrt/-/issues/2278RFE: Replace iptables(legacy) with iptables(nf_tables)2019-09-10T10:45:32ZaparcarRFE: Replace iptables(legacy) with iptables(nf_tables)Username: Xose Vazquez Perez
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2278
Supported since iptables 1.8:
https://marc.info/?l=netfilter-devel&m=153086953903487Username: Xose Vazquez Perez
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2278
Supported since iptables 1.8:
https://marc.info/?l=netfilter-devel&m=153086953903487https://code.fe80.eu/openwrt/openwrt/-/issues/2269iwinfo_lib.c does not correlate it's list with kernel2019-09-10T10:45:49Zaparcariwinfo_lib.c does not correlate it's list with kernelUsername: nero
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2269
The following issue occurs on all devices across all OpenWRT versions as it is partly a problem derived from the Linux Kernel.
It is explained in detail...Username: nero
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2269
The following issue occurs on all devices across all OpenWRT versions as it is partly a problem derived from the Linux Kernel.
It is explained in detail here:
https://forum.openwrt.org/t/wifi-regulatory-country-database/35775
Prerequisites:
1) You need to have set up a working Wireless access point.
2) The set country has to not be one of the ones patched out here:
https://pastebin.com/M2qTQFT5
Steps to reproduce:
1) Type ‘iw reg get’ in the terminal. This will give you a list of all available channels in the regulatory zone (country).
2) Change country to one of the patched out ones:
https://pastebin.com/M2qTQFT5
(Eg. Angola, Antarctica)
3) [opt - Disregard this step if you used the WebUI] Type ‘/etc/init.d/network restart’ 4) Type ‘iw reg get’ in the terminal. You will notice that it has not changed.
Problem:
You can, unknown to you, set up a channel which is prohibited in your country. This is very hard to *check* because there is no way to pre-query whether you can set such a country or not.
More detailed explanation and argumentation can be found here:
https://forum.openwrt.org/t/wifi-regulatory-country-database/35775https://code.fe80.eu/openwrt/openwrt/-/issues/2083Remove last references to the lede-project.org URL2019-09-10T10:45:09ZaparcarRemove last references to the lede-project.org URLUsername: Xose Vazquez Perez
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2083
git grep -i “lede-project\.org” | grep -vi Copyright
There are still some references to the old project.
Thanks.Username: Xose Vazquez Perez
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=2083
git grep -i “lede-project\.org” | grep -vi Copyright
There are still some references to the old project.
Thanks.https://code.fe80.eu/openwrt/openwrt/-/issues/1777release 18.06 on RouterBoards (ar71xx/mikrotik): superfluous UBI volume2019-09-10T10:44:42Zaparcarrelease 18.06 on RouterBoards (ar71xx/mikrotik): superfluous UBI volumeUsername: Adolf Berthold
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1777
The sysupgrade-procedure of release 18.06 for RouterBoards (ar71xx/mikrotik)
(as contained in openwrt-18.06.0-ar71xx-mikrotik-vmlinux-initram...Username: Adolf Berthold
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1777
The sysupgrade-procedure of release 18.06 for RouterBoards (ar71xx/mikrotik)
(as contained in openwrt-18.06.0-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf) creates
a superfluous UBI volume named “none”.
Details:
The function platform_nand_pre_upgrade() intarget/linux/ar71xx/base-files/lib/upgrade/platform.sh sets
“CI_KERNPART=none” to bypass the normal kernel-install-procedure.
This works, but causes nand_upgrade_prepare_ubi() in package/base-files/files/lib/upgrade/nand.sh
to creat an UBI volume named “none”, containing a (supposedly defective) kernel-yaffs2-image.
Used command :
sysupgrade -n -v
http://192.168.88.1:8080/openwrt-18.06.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.binhttps://code.fe80.eu/openwrt/openwrt/-/issues/1523block-mount: unnecessary remounts after extroot switch2019-09-10T10:42:56Zaparcarblock-mount: unnecessary remounts after extroot switchUsername: Andreas
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1523
Environment: arm_cortex-a9_vfpv3, Linksys WRT1200AC, LEDE Reboot 17.01.4 r3560-79f57e422d
Description:
A USB flash drive has been configured with an...Username: Andreas
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1523
Environment: arm_cortex-a9_vfpv3, Linksys WRT1200AC, LEDE Reboot 17.01.4 r3560-79f57e422d
Description:
A USB flash drive has been configured with an ext4 partition to be used as external overlay, following the steps at
https://openwrt.org/docs/guide-user/additional-software/extroot_configuration
precisely. After the extroot switch, block tries to remount partitions that have already been mounted, generating the following errors in the logs:
Sat Apr 28 12:25:00 2018 daemon.err block: /dev/ubiblock0_0 is already mounted on /rom
Sat Apr 28 12:25:00 2018 daemon.err block: /dev/sdb1 is already mounted on /overlayhttps://code.fe80.eu/openwrt/openwrt/-/issues/1415[Enhancement] Consider shorter interface-name prefixes2019-09-10T10:44:03Zaparcar[Enhancement] Consider shorter interface-name prefixesUsername: Jeff Kletsky
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1415
Given that `IFNAMSIZ` is typically 16, there are 15 characters available for an interface name.
OpenWRT prepends a prefix that can be at least 6...Username: Jeff Kletsky
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1415
Given that `IFNAMSIZ` is typically 16, there are 15 characters available for an interface name.
OpenWRT prepends a prefix that can be at least 6 characters `gre4t-` as an example.
If one then creates pseudo/virtual-interfaces using VLAN notation, there are only 4 characters available for configuration
`gre4t-ABCD.1234`
As long as this limitation is known, there is no loss of functionality, only utility in the naming. I would have ideally been able to name my tunnels with a more readable indication of where the other endpoint was, for example `portal1` rather than `gt99`.
At some time in the future, shortening these generated prefixes would be welcome. I acknowledge that this likely impacts only a small fraction of advanced users and a change may impact scripts that rely on the generated name.https://code.fe80.eu/openwrt/openwrt/-/issues/1414mbedtls: building with ccache: /staging_dir/host/bin/ccache: invalid option -...2019-09-10T10:43:48Zaparcarmbedtls: building with ccache: /staging_dir/host/bin/ccache: invalid option -- 'd'Username: Drei Eck
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1414
I am currently trying to compile OpenWRT for
CONFIG_TARGET_LANTIQ=Y
CONFIG_TARGET_LANTIQ_XWAY=Y
CONFIG_TARGET_lantiq_xway_DEVICE_arcadyan_arv752dpw2...Username: Drei Eck
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1414
I am currently trying to compile OpenWRT for
CONFIG_TARGET_LANTIQ=Y
CONFIG_TARGET_LANTIQ_XWAY=Y
CONFIG_TARGET_lantiq_xway_DEVICE_arcadyan_arv752dpw22=y
I am using
CONFIG_DEVEL=y
CONFIG_CCACHE=y
I am building in the following way:
The build was carried out on a
git clone git://github.com/openwrt/openwrt.git
, later brought up to date with a
git pull
, with latest commit from 2018-03-05T10:44:20+01:00, commit hash 5cbd22bb0f.
Into this
git clone
a previously generated .config seed, made previously by
make menuconfig
and
./scripts/diffconfig.sh
, was copied over to
./.config
.
From there on, the following commands were issued:
./scripts/feeds update -a
./scripts/feeds install -a
make -j1 V=s defconfig
make -j1 V=s download
make -j1 V=s IGNORE_ERRORS=m | tee make.log
When it comed to building mbedtls, there are the following lines of output which indicate something is wrong:
[...]
make[3]: [Makefile:75: /home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/2018-02-26_12-04-45_-_custom-wo-pie_feeds-rooter-custom/build_dir/target-mips_24kc_musl/mbedtls-2.7.0/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 123 (ignored)
[...]
/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/2018-02-26_12-04-45_-_custom-wo-pie_feeds-rooter-custom/staging_dir/host/bin/ccache: invalid option -- 'd'
Usage:
ccache [options]
[...]
Build continues, (seemingliy) successfully: Indicated by the further output of
make
, and issuing later a
make -j1 V=s
(i.e. without
IGNORE_ERRORS=m
), does not bring this up again.
The toolchain (
./staging_dir/toolchain-*
) is
mips_24kc_gcc-5.5.0_musl
.
Build is carried out on an x86_64 Arch Linux machine.
Attached are the following files:
.config-diffconfig-seed
: The .config-seed used for make defconfig,
.config
: The
.config
created by the make defconfig and used for the build,
mbedtls.log
: The pa[.config-diffconfig-seed.txt](
https://github.com/openwrt/packages/files/1782373/default.config-diffconfig-rt
of the output of
make -j1 V=s IGNORE_ERRORS=m
regarding building mbedtls,
make.log.stdout.xz
: For your interest, the full output of
make -j1 V=s IGNORE_ERRORS=m
(.xz compressed; decompresses to about 29
MB
) (Note that at the end another build error occurs, which seems not to be related to embedtls),
feeds.conf
: The
feeds.conf
used.
(Note that I just forgot to capture stderr too, but the error messages seem to be present in stdout. Since a full rebuild takes a day on my machine, I won’t do that if not necessary.)https://code.fe80.eu/openwrt/openwrt/-/issues/1339It seems that ‘–dport’ option is not recognized by iptables for sctp.2019-09-10T10:44:27ZaparcarIt seems that ‘–dport’ option is not recognized by iptables for sctp.Username: z 237751
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1339
Mys router:
System: CHAOS CALMER (15.05.1, r48532)
Router: Asus RT-N56U
I also reproduced this bug with lede 17.01.1 r3316-7eb58cf109 in VirtualBo...Username: z 237751
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=1339
Mys router:
System: CHAOS CALMER (15.05.1, r48532)
Router: Asus RT-N56U
I also reproduced this bug with lede 17.01.1 r3316-7eb58cf109 in VirtualBox (according to the guide on
https://wiki.openwrt.org/doc/howto/virtualbox
).
What happens:
It seems that ‘–dport’ option is not recognized by iptables for sctp. Command execution fails.
Expected result:
Command runs successfully and we can create rules with iptables to match by sctp and destination port.
Steps to reproduce:
First install these:
sctp
kmod-sctp
libsctp
sctp-tools
Try to run this:
iptables -A INPUT -p sctp --dport 1234 -j ACCEPT
Shows error:
iptables v1.4.21: unknown option "--dport"
Try `iptables -h' or 'iptables --help' for more information.
Try to run this:
iptables -A INPUT -p sctp -j ACCEPT
Works!https://code.fe80.eu/openwrt/openwrt/-/issues/989Attempting to just build iptables fails2019-09-10T10:42:52ZaparcarAttempting to just build iptables failsUsername: Nathaniel Wesley Filardo
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=989
Using LEDE HEAD (currently 4b3ffecf2bbbfb8df618314e5bec52659b648fac), running “make defconfig; make -j1 V=s package/iptables/compiles”...Username: Nathaniel Wesley Filardo
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=989
Using LEDE HEAD (currently 4b3ffecf2bbbfb8df618314e5bec52659b648fac), running “make defconfig; make -j1 V=s package/iptables/compiles” in a fresh checkout yields
make[1]: Entering directory '/tank/openwrt/scratch/test'
make[2]: Entering directory '/tank/openwrt/scratch/test/package/libs/toolchain'
touch /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.prepared_9c30076b46b1812fb254b6ec31ccf85e_6664517399ebbbc92a37c5bb081b5c53_check
mkdir -p /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain
touch /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.prepared_9c30076b46b1812fb254b6ec31ccf85e_6664517399ebbbc92a37c5bb081b5c53
rm -f /tank/openwrt/scratch/test/staging_dir/target-mips_24kc_musl/stamp/.toolchain_installed
(cd /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/./; if [ -x ./configure ]; then find /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/ -name config.guess | xargs -r chmod u+w; find /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/ -name config.guess | xargs -r -n1 cp --remove-destination /tank/openwrt/scratch/test/scripts/config.guess; find /tank/openwrt/s
cratch/test/build_dir/target-mips_24kc_musl/toolchain/ -name config.sub | xargs -r chmod u+w; find /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/ -name config.sub | xargs -r -n1 cp --remove-destination /tank/openwrt/scratch/test/scripts/config.sub; AR="mips-openwrt-linux-musl-gcc-ar" AS="mips-openwrt-linux-musl-gcc -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -f
honour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -iremap/tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain:toolchain -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro" LD=mips-openwrt-linux-musl-ld NM="mips-openwrt-linux-musl-gcc-nm" CC="mips-openwrt-linux-musl-gcc" GCC="mips-openwrt-linux-musl-gcc" CPP="mips-openwrt-linu
x-musl-cpp" CXX="mips-openwrt-linux-musl-g++" RANLIB="mips-openwrt-linux-musl-gcc-ranlib" STRIP=mips-openwrt-linux-musl-strip OBJCOPY=mips-openwrt-linux-musl-objcopy OBJDUMP=mips-openwrt-linux-musl-objdump SIZE=mips-openwrt-linux-musl-size CFLAGS="-Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -
minterlink-mips16 -iremap/tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain:toolchain -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro " CXXFLAGS="-Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -minterlink-mips16 -iremap/tank/openwr
t/scratch/test/build_dir/target-mips_24kc_musl/toolchain:toolchain -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro " CPPFLAGS="-I/tank/openwrt/scratch/test/staging_dir/target-mips_24kc_musl/usr/include -I/tank/openwrt/scratch/test/staging_dir/target-mips_24kc_musl/include -I/tank/openwrt/scratch/test/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl/usr/include -I/tank/openwrt
/scratch/test/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl/include/fortify -I/tank/openwrt/scratch/test/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl/include " LDFLAGS="-L/tank/openwrt/scratch/test/staging_dir/target-mips_24kc_musl/usr/lib -L/tank/openwrt/scratch/test/staging_dir/target-mips_24kc_musl/lib -L/tank/openwrt/scratch/test/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl/usr/lib -L/tank/openwrt/scratch/test/
staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl/lib -znow -zrelro " ./configure --target=mips-openwrt-linux --host=mips-openwrt-linux --build=x86_64-pc-linux-gnu --program-prefix="" --program-suffix="" --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var --mandir=/usr/man --infodir=/usr/info --disable-nls ; fi; )
rm -f /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.configured_*
touch /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.configured_68b329da9893e34099c7d8ad5cb9c940
rm -f /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.built
touch /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.built_check
touch /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.built
rm -rf /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc.installed /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc
mkdir -p /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc
install -d -m0755 /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc/lib /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc/usr/bin
cp -fpR /tank/openwrt/scratch/test/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl/lib/ld-musl-*.so* /tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc/lib/
cp: cannot stat '/tank/openwrt/scratch/test/staging_dir/toolchain-mips_24kc_gcc-5.4.0_musl/lib/ld-musl-*.so*': No such file or directory
Makefile:618: recipe for target '/tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc.installed' failed
make[2]: *** [/tank/openwrt/scratch/test/build_dir/target-mips_24kc_musl/toolchain/.pkgdir/libc.installed] Error 1
make[2]: Leaving directory '/tank/openwrt/scratch/test/package/libs/toolchain'
package/Makefile:109: recipe for target 'package/libs/toolchain/compile' failed
make[1]: *** [package/libs/toolchain/compile] Error 2
make[1]: Leaving directory '/tank/openwrt/scratch/test'
/tank/openwrt/scratch/test/include/toplevel.mk:207: recipe for target 'package/iptables/compile' failed
make: *** [package/iptables/compile] Error 2
If I just run “make” the system builds successfully, so I am not exactly sure what’s wrong. Perhaps it’s as simple as a missing dependency? This came about because I was attempting to build iptables without having built the kernel and was getting yet different build failures, but I have not reliably reproduced them from a blank slate yet. Will advise.https://code.fe80.eu/openwrt/openwrt/-/issues/854Unstable Internet caused by frequent PPPoE reconnect, network.wan.keepalive=0...2019-09-10T10:41:29ZaparcarUnstable Internet caused by frequent PPPoE reconnect, network.wan.keepalive=0 has no effectUsername: ppuzr
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=854
Problem occurs on EE Brightbox 1 (Arcadyan AR7516)
Software version is lede 17.01.1, r3316-7eb58cf109 (
https://downloads.lede-project.org/releases/17....Username: ppuzr
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=854
Problem occurs on EE Brightbox 1 (Arcadyan AR7516)
Software version is lede 17.01.1, r3316-7eb58cf109 (
https://downloads.lede-project.org/releases/17.01.1/targets/brcm63xx/generic/lede-17.01.1-brcm63xx-generic-A4001N-squashfs-cfe.bin
)
Steps to reproduce: after a PPPoE session has been established for a while, it reconnects and the following messages appear in the log
daemon.info pppd[7738]: No response to 5 echo-requests
daemon.notice pppd[7738]: Serial link appears to be disconnected.
daemon.info pppd[7738]: Connect time 1.0 minutes.
daemon.info pppd[7738]: Sent 28006 bytes, received 46170 bytes.
daemon.notice pppd[7738]: Connection terminated.
daemon.info pppd[7738]: Connect time 1.0 minutes.
daemon.info pppd[7738]: Sent 28006 bytes, received 46170 bytes.
daemon.info pppd[7738]: Sent PADT
daemon.info pppd[7738]: Exit.
network.wan.keepalive is not set, and on luci “LCP echo failure threshold” shows a grey 0 and the description below it says “Presume peer to be dead after given amount of LCP echo failures, use 0 to ignore failures”, but this description is not consistent with the behaviour.
After running the commands below, the grey 0 becomes darker, but the problem persists.
root@LEDE:~# uci set network.wan.keepalive=0
root@LEDE:~# /etc/init.d/network restart
The value of network.wan.keepalive when set using luci has two numbers separated by a space (which appears to be in the format of ‘[threshold] [interval]’), but it should be a number according to the wiki
https://lede-project.org/docs/user-guide/wan_interface_protocols?s[]=pppoe#protocol_pppoe_ppp_over_ethernet
I then tried the following commands, and there’re no reconnects after one hour.
root@LEDE:~# uci set network.wan.keepalive='0 1'
root@LEDE:~# /etc/init.d/network restart
Is it better to have a default of 0 (default=undefined network.wan.keepalive) instead of seemingly 5 which would also be consistent with luci?https://code.fe80.eu/openwrt/openwrt/-/issues/772Allowing Snort to also block possibly using SnortSam2019-09-10T10:41:11ZaparcarAllowing Snort to also block possibly using SnortSamUsername: LLEACHII
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=772
I noticed that Snort is available from the packages. I wanted to inquire if it would be possible to intergrate dynamic blocking through software such ...Username: LLEACHII
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=772
I noticed that Snort is available from the packages. I wanted to inquire if it would be possible to intergrate dynamic blocking through software such as SnortSam (
http://www.snortsam.net/
).
pfSence implements a blocking feature with Snort, I’m curious if others may be likewise be interested in this feature being added in to a future release of LEDE.
Thankshttps://code.fe80.eu/openwrt/openwrt/-/issues/751Add customisable SIGINT behaviour to procd2019-09-10T10:41:53ZaparcarAdd customisable SIGINT behaviour to procdUsername: multiplexd
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=751
I am running LEDE 17.01.1 on a Linksys NSLU2.
The device has a power button on the front panel, which will boot the device when pressed when power ...Username: multiplexd
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=751
I am running LEDE 17.01.1 on a Linksys NSLU2.
The device has a power button on the front panel, which will boot the device when pressed when power is present. If the button is pressed when the device is running the device will reboot. I would like to be able to configure the device to power off when the button is pressed instead.
I have tried editing some of the stock scripts in /etc/rc.button to no effect. I ran across
this page
on the OpenWrt wiki, which suggests that pressing the button causes SIGINT to be delivered to PID 1.
I took a look at the procd git repository, and procd reboots the system when it catches SIGINT. If this were configurable then procd could take specific action, such as powering the device down, when it receives a hardware interrupt.https://code.fe80.eu/openwrt/openwrt/-/issues/732D-Link DIR-615 D2 (ramips rt305x) Wireless LED Not Flashing Solid Green2019-09-10T10:40:38ZaparcarD-Link DIR-615 D2 (ramips rt305x) Wireless LED Not Flashing Solid GreenUsername: Francis
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=732
I have a D-Link DIR-615 D2 (dir-615-d-squashfs-factory.bin), Its all working fine however the LED for the wireless light dosnt flash nor show activity ...Username: Francis
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=732
I have a D-Link DIR-615 D2 (dir-615-d-squashfs-factory.bin), Its all working fine however the LED for the wireless light dosnt flash nor show activity to show is been used as it shows a solid green WiFi light. LANs from 1-4 all flash perfectly so no issue here.https://code.fe80.eu/openwrt/openwrt/-/issues/568First boot messages are not logged to file2019-09-10T10:39:42ZaparcarFirst boot messages are not logged to fileUsername: Andreas
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=568
I’m saving logs to a file on an external partition that is mounted at boot. After rebooting with an empty log file, an inconsistency can be noticed bet...Username: Andreas
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=568
I’m saving logs to a file on an external partition that is mounted at boot. After rebooting with an empty log file, an inconsistency can be noticed between the output of logread and the content of the log file. The first message printed by logread is, as expected,
Mon Feb 27 20:33:15 2017 kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0
while the first message in the log file reads
Mon Feb 27 20:33:16 2017 user.notice : Added device handler type: tunnel
The first boot messages are missing from the log file. From this point on, logread and the log file are identical.
Of course this is a minor issue, but still one would expect logs to be 100% complete, regardless whether they are stored in memory or to file.
root@lede:~# cat /etc/config/system
config system
option hostname 'lede'
option zonename 'Europe/Rome'
option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
option ttylogin '0'
option urandom_seed '0'
option log_remote '0'
option log_type 'file'
option log_file '/mnt/sda1/var/log/messages'
option log_buffer_size '64'
option log_size '1024'
option conloglevel '8'
option cronloglevel '0'
...
Start order of init scripts log and fstab has been changed to start logging as early as possible.
root@lede:~# ls -1 /etc/rc.d/S*
/etc/rc.d/S00sysfixtime
/etc/rc.d/S10boot
/etc/rc.d/S10fstab
/etc/rc.d/S10system
/etc/rc.d/S11log
/etc/rc.d/S11sysctl
...
Device: WRT1200AC
Software version: Reboot (17.01.0, r3205-59508e3)https://code.fe80.eu/openwrt/openwrt/-/issues/517PCEngines Alix Ethernet right hand led lit on boot for all ports with no cabl...2019-09-10T10:40:30ZaparcarPCEngines Alix Ethernet right hand led lit on boot for all ports with no cable connected 17.01.0-rc2Username: Rob White
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=517
PCEngines Alix, Ethernet right hand led is on once booted, on all ports, with no cable connected.
LEDE Reboot 17.01.0-rc2
Image used: lede-17.01.0-...Username: Rob White
Origin: https://bugs.openwrt.org/index.php?do=details&task_id=517
PCEngines Alix, Ethernet right hand led is on once booted, on all ports, with no cable connected.
LEDE Reboot 17.01.0-rc2
Image used: lede-17.01.0-rc2-r3131-42f3c1f-x86-geode-combined-squashfs.img
On booting the right hand LED is on for all ethernet ports with no cable connected. On connecting a cable the left hand light comes on as expected and the right hand stays on. Both leds then flash with traffic as expected.
Operation is not effected.