[PATCH] odhcp6c: add "verbose" option
odhcp6c logs messages related to its activity when invoked with -v, but
there is no way to configure this from within OpenWrt. This adds a UCI
option to turn on odhcp6c logging, disabled by default. To enable, set,
for example, network.wan6.verbose = 1.
Signed-off-by: Mark Mentovai
---
package/network/ipv6/odhcp6c/Makefile| 2 +-
package/network/ipv6/odhcp6c/files/dhcpv6.sh | 7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/package/network/ipv6/odhcp6c/Makefile
b/package/network/ipv6/odhcp6c/Makefile
index 505aa56e4167..7ad3a1cfcd06 100644
--- a/package/network/ipv6/odhcp6c/Makefile
+++ b/package/network/ipv6/odhcp6c/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=odhcp6c
-PKG_RELEASE:=19
+PKG_RELEASE:=20
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/odhcp6c.git
diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.sh
b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
index ac8c7797fb9f..8c2a0859cb4f 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.sh
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.sh
@@ -39,6 +39,7 @@ proto_dhcpv6_init_config() {
proto_config_add_boolean sourcefilter
proto_config_add_boolean keep_ra_dnslifetime
proto_config_add_int "ra_holdoff"
+ proto_config_add_boolean verbose
}
proto_dhcpv6_add_prefix() {
@@ -53,8 +54,8 @@ proto_dhcpv6_setup() {
local config="$1"
local iface="$2"
- local reqaddress reqprefix clientid reqopts defaultreqopts noslaaconly
forceprefix extendprefix norelease noserverunicast noclientfqdn
noacceptreconfig ip6prefix ip6prefixes iface_dslite iface_map iface_464xlat
ifaceid userclass vendorclass sendopts delegate zone_dslite zone_map
zone_464xlat zone encaplimit_dslite encaplimit_map soltimeout fakeroutes
sourcefilter keep_ra_dnslifetime ra_holdoff
- json_get_vars reqaddress reqprefix clientid reqopts defaultreqopts
noslaaconly forceprefix extendprefix norelease noserverunicast noclientfqdn
noacceptreconfig iface_dslite iface_map iface_464xlat ifaceid userclass
vendorclass delegate zone_dslite zone_map zone_464xlat zone encaplimit_dslite
encaplimit_map soltimeout fakeroutes sourcefilter keep_ra_dnslifetime ra_holdoff
+ local reqaddress reqprefix clientid reqopts defaultreqopts noslaaconly
forceprefix extendprefix norelease noserverunicast noclientfqdn
noacceptreconfig ip6prefix ip6prefixes iface_dslite iface_map iface_464xlat
ifaceid userclass vendorclass sendopts delegate zone_dslite zone_map
zone_464xlat zone encaplimit_dslite encaplimit_map soltimeout fakeroutes
sourcefilter keep_ra_dnslifetime ra_holdoff verbose
+ json_get_vars reqaddress reqprefix clientid reqopts defaultreqopts
noslaaconly forceprefix extendprefix norelease noserverunicast noclientfqdn
noacceptreconfig iface_dslite iface_map iface_464xlat ifaceid userclass
vendorclass delegate zone_dslite zone_map zone_464xlat zone encaplimit_dslite
encaplimit_map soltimeout fakeroutes sourcefilter keep_ra_dnslifetime
ra_holdoff verbose
json_for_each_item proto_dhcpv6_add_prefix ip6prefix ip6prefixes
# Configure
@@ -90,6 +91,8 @@ proto_dhcpv6_setup() {
[ -n "$ra_holdoff" ] && append opts "-m$ra_holdoff"
+ [ "$verbose" = "1" ] && append opts "-v"
+
local opt
for opt in $reqopts; do
append opts "-r$opt"
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: disable stack validation for external module builds as needed
c3e31b6a9b04 and 5f8e5872406d disable stack validation when the build host is not running Linux, as the objtool kernel build tool required for stack validation is not portable to other build host environments. This was achieved by setting CONFIG_STACK_VALIDATION= in KERNEL_MAKEOPTS, and by setting SKIP_STACK_VALIDATION=1 in the environment. KERNEL_MAKEOPTS only has effect for the kernel build, not for external module builds, but through kernel 5.14, SKIP_STACK_VALIDATION worked to disable this feature too, so stack validation was disabled for external module builds as well. Since kernel 0d989ac2c90b, the kernel build no longer considers SKIP_STACK_VALIDATION, so the feature will be disabled for the kernel build, but not for external module builds. When building OpenWrt on a non-Linux build host targeting x86 (the only target architecture for which OpenWrt enables the kernel CONFIG_STACK_VALIDATION) and using kernel 5.15 (such as via CONFIG_TESTING_KERNEL), this caused a build failure during any external module build, such as kmod-button-hotplug. This manifested as build errors such as: make[4]: *** No rule to make target '.../build_dir/target-x86_64_musl/linux-x86_64/button-hotplug/button-hotplug.o', needed by '.../build_dir/target-x86_64_musl/linux-x86_64/button-hotplug/button-hotplug.mod'. Stop. Although button-hotplug.c was present, the implicit rule to make $(obj)/%.o from $(src)/%.c in the kernel's scripts/Makefile.build could not be satisfied in this case, as it also depends on $(objtool_dep), non-empty as a result of the failure to propagate disabling of stack validation to external module builds, in a configuration where it is not possible to build objtool. KERNEL_MAKEOPTS is used for just the kernel build itself, while KERNEL_MAKE_FLAGS is used for both the kernel build and for external module builds. This restores the ability to build OpenWrt in such configurations by moving the CONFIG_STACK_VALIDATION= make argument from KERNEL_MAKEOPTS to KERNEL_MAKE_FLAGS where it is able to affect external module builds properly. Note that the kernel's objtool and related configuration have seen a major overhaul since kernel 5.15, and may need more attention again after 22922deae13f, in kernel 5.19. Signed-off-by: Mark Mentovai --- include/kernel.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel.mk b/include/kernel.mk index 001718d89d8b..3cc2fc41b7a0 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -132,7 +132,7 @@ ifdef CONFIG_USE_SPARSE endif ifneq ($(HOST_OS),Linux) - KERNEL_MAKEOPTS += CONFIG_STACK_VALIDATION= + KERNEL_MAKE_FLAGS += CONFIG_STACK_VALIDATION= export SKIP_STACK_VALIDATION:=1 endif -- 2.37.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bridge-vlan bug? (mt7621/DSA)
Thibaut wrote: I’m experiencing a strange bug on Yuncore AX820 (mt7621/mt7905/mt7975, DSA-enabled) when using a bridge-vlan setup. This bug affects at least OpenWRT 22.03.0-rc6. I’m not sure whether this bug is related to this particular SoC or only to DSA as I was unable to test with another DSA-enabled device (I don’t have any). However this bug does not affect e.g. QCA non-DSA devices. I’m running out of ideas on how to further debug this problem, so feel free to guide me if more information is needed. Please CC-me in replies. This sounds very similar to the problem I experienced with the work-in-progress DSA patches for ipq40xx: https://github.com/openwrt/openwrt/pull/4721#issuecomment-971162067 This kernel patch explains the situation fairly well: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5f19486cee79d04c054427577ac96ed123706db But the fix isn’t operative unless the switch driver opts in via assisted_learning_on_cpu_port. There were also comments from around that time that there may still be trouble with untagged traffic. There’s a bit of discussion about this issue in the comments around there on the pull request. Hopefully you’ll find it helpful. It should at least get you oriented in the right direction, even if it’s not a fix for your untagged use case. == Hardware setup == - 1 router (any router works for the purpose of the test), serving DHCP on the LAN (the default configuration from a fresh OpenWRT install works to reproduce this bug - the router setup has not play in the bug). - 1 AX820 setup as « dumb » AP (testcase config provided below, using a bridge-vlan), with one uplink interface (here ‘wan’) directly connected to the router - 1 other AP, make/model irrelevant, provided it has the same dumb config as the AX820 and is also directly connected to the router The APs use a single bridge-vlan to which their interfaces are hooked: in the full scenario multiple VLANs are assigned to the bridge, and assigned to separate SSIDs. All but one VLANs are tagged on the uplink interface. The reduced test case config provided below uses a single untagged VLAN (id 8, for network ‘lan’) and a single SSID: that is enough to expose the bug. == Bug description == The following bug happens on the untagged VLAN on the uplink interface (see testcase config below): When a client device roams to the AX820 AP (which can be forced by issuing « wifi off » on the other AP when the client is connected to it), a « blackout » period that typically lasts 2-5mn begins, where the client loses connectivity. The stale entries persist in the FDB with a 5-minute timeout, so this aligns. You can use “bridge fdb show” to see this happening, and “bridge fdb del” to delete entries before they time out. This comment and the gists linked in the one after have more information on a test environment: https://github.com/openwrt/openwrt/pull/4721#issuecomment-974911742 Mark == Analysis == Running tcpdump, one obvious symptom is that the client emits DHCP requests which are received by the router, the router sends back DHCP replies (confirmed via tcpdump on router) but these replies never reach the client during the blackout period. In fact, running tcpdump on all of the connected AP’s interface (wireless (wlan0), DSA slave (wan), DSA master (eth0), 8021q (vlan-lan), bridge-vlan (vbridge0)) shows no DHCP reply ever being captured during this blackout period, until one finally makes it through when the blackout ends. == Known unaffected scenarios == If the VLAN is configured tagged on the uplink interface (using « list ports ‘wan:t’ ») - and the router is setup to use tagged frames as well of course - the bug does not occur. If the slaves are configured with regular ‘br-lan’ bridges (no vlans), the bug does not occur: it seems tied to using a bridge-vlan. « roaming » a wired device from one AP to the other (through the free ethernet port configured untagged, see testcase config below) does not trigger the bug: wireless seems a key part of this problem. Finally, the exact same AP configuration used on non-DSA QCA9533-based devices works flawlessly. == Other remarks == To decode DSA master interface (eth0) captures, I used editcap (from Wireshark) as follows: $ editcap -L -T ether -C 12:4 dsamaster.cap master.cap this removes the mtk DSA tags that libpcap cannot parse. == Reduced testcase AP configs == /etc/config/network (loopback config not quoted, adjust ipaddr for each AP): config interface 'lan' option proto 'static' option netmask '255.255.255.0' option ip6assign '60' option device 'vlan-lan' option ipaddr '192.168.1.2' option gateway '192.168.1.1' option dns '192.168.1.1' config device option type 'bridge' option name 'vbridge0' option ipv6 '0' option vlan_filtering '1' list ports 'lan' list
Re: [PATCH v2] failsafe: console failsafe shell improvements
I wrote:
When running a failsafe shell on a console, job control was unavailable,
and ^C did not function correctly.
This change invokes console failsafe shells via `setsid`, making them
session leaders and allowing them to claim controlling terminals, which
makes job control function properly. To support this, the busybox
`setsid` utility is enabled. This has a minimal 149-byte size impact on
a test x86_64 squashfs rootfs image.
^C was causing console failsafe shell itself to exit, and was being
ignored in subprocesses of such shells: it was not possible to ^C out of
a program that would not exit on its own, such as many typical `ping`
invocations. As job control was unavailable, it was not possible to
suspend these subprocesses either, causing a hung program to tie up a
console indefinitely, unless another means to signal the program was
available. This was caused by SIGINT being placed at disposition SIG_IGN
by the shell running preinit, which it did because the console shell was
executed asynchronously with &. That disposition was inherited by the
console shell and its subprocesses, generally causing ^C to have no
effect. In the console shell itself, although SIGINT was ignored, ^C
caused the read loop to return with nothing read, which the shell
"converted" to SIGINT, causing it to exit.
Is there any interest in or feedback on this patch? It's a significant
improvement to the failsafe shell's usability on serial consoles.
(Cc chunkeey as the commiter of c9725d4fb620, my previous failsafe
improvement that this one follows.)
As there is no way in busybox `ash` to reset the disposition of a signal
already ignored at shell entry, and no apparent way to avoid SIGINT
being placed at SIG_IGN when & is used in preinit, an alternative
construct is needed. Now, `start-stop-daemon` is used to start (-S) the
console failsafe shell in the background (-b). This approach does not
alter SIGINT, allowing the console shell to be started with that
signal's handling intact, and normal ^C processing to occur.
busybox `ash` has some behaviors conditional on SHLVL, and while the
console shells ought to run at SHLVL=1, they were not by virtue of being
started by the shell-based preinit system. Additionally, a variety of
detritus was present in the console shell's environment, carried over
from preinit. These conditions are corrected by running the console
shell via `env -i` to clear the environment and establish a minimum and
correct set of environment variables for operation, in the same manner
as `login`. HOME is not explicitly set, because it's addressed in
/etc/profile. For non-failsafe console shells when
system.@system[0].ttylogin = 0, `login -f root` achieves a similar
effect. (`login` already started non-failsafe console shells when
ttylogin = 1 and behaved correctly. This brings the ttylogin = 0 case to
parity.) Note that even `login -f` is somewhat undesirable for failsafe
shells because it requires a viable /etc/passwd, hence the `env -i`
construct in that case.
The TERM environment variable from the preinit environment, with value
"linux", would rarely be correct for serial consoles. Now, the preinit
TERM value is preserved (or set to "linux" if unset) only when the
console is /dev/console or /dev/tty[0-9]*. Otherwise, it will be set to
a safe default appropriate for serial consoles, "vt102". This change is
also duplicated for non-failsafe console shells.
This also indicates failsafe mode by showing "- failsafe -" on all
consoles (not just the last-defined one). It sets a hostname of
"OpenWrt-failsafe" in failsafe mode which is rendered in the shell's
prompt as a reminder of the mode during interactive failsafe use.
Previously, no hostname was set, which resulted in the kernel-default
hostname, "(none)", appearing in failsafe shell prompts.
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/10_indicate_failsafe | 7 ++-
.../files/lib/preinit/30_failsafe_wait | 5 -
.../files/lib/preinit/99_10_failsafe_login | 18 +-
package/base-files/files/usr/libexec/login.sh | 14 +-
package/utils/busybox/Config-defaults.in | 2 +-
5 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_failsafe
b/package/base-files/files/lib/preinit/10_indicate_failsafe
index 7bf5e029e42f..8c950bff74d0 100644
--- a/package/base-files/files/lib/preinit/10_indicate_failsafe
+++ b/package/base-files/files/lib/preinit/10_indicate_failsafe
@@ -9,9 +9,14 @@ indicate_failsafe_led () {
indicate_failsafe() {
[ "$pi_preinit_no_failsafe" = "y" ] && return
- echo "- failsafe -"
+ local consoles="$(cat /sys/class/tty/console/active)"
+ [ -n "$consoles" ] || consoles=console
+ for console in $consoles; do
+ [ -c "/dev/$console"
[PATCH v2] libmnl: fix build when bash is not located at /bin/bash
This fixes the libmnl build on macOS, which ships with an outdated bash
at /bin/bash. During the OpenWrt build, a modern host bash is built and
made available at staging_dir/host/bin/bash, which is present before
/bin/bash in the build's PATH.
This is similar to 8f7ce3aa6dda, presently appearing at
package/kernel/mac80211/patches/build/001-fix_build.patch.
Signed-off-by: Mark Mentovai
---
package/libs/libmnl/patches/001-fix_build.patch | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 package/libs/libmnl/patches/001-fix_build.patch
diff --git a/package/libs/libmnl/patches/001-fix_build.patch
b/package/libs/libmnl/patches/001-fix_build.patch
new file mode 100644
index ..030020abacbe
--- /dev/null
+++ b/package/libs/libmnl/patches/001-fix_build.patch
@@ -0,0 +1,11 @@
+--- a/doxygen/Makefile.am
b/doxygen/Makefile.am
+@@ -21,7 +21,7 @@
+ # The command has to be a single line so the functions work
+ # and so `make` gives all lines to `bash -c`
+ # (hence ";\" at the end of every line but the last).
+- /bin/bash -p -c 'declare -A renamed_page;\
++ bash -p -c 'declare -A renamed_page;\
+ main(){ set -e; cd man/man3; rm -f _*;\
+ count_real_pages;\
+ rename_real_pages;\
--
2.37.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] libmnl: fix build when bash is not located at /bin/bash
Hauke Mehrtens wrote: On 6/21/22 16:38, Mark Mentovai wrote: From: Mark Mentovai This fixes the libmnl build on macOS, which ships with an outdated bash at /bin/bash. During the OpenWrt build, a modern host bash is built and made available at staging_dir/host/bin/bash, which is present before /bin/bash in the build's PATH. This is similar to 8f7ce3aa6dda, presently appearing at package/kernel/mac80211/patches/build/001-fix_build.patch. Signed-off-by: Mark Mentovai The author email address in the From field and the Signed-off-by line do not match. The rest of the patch looks ok. That’s git-send-email trying to make a fool of me. I’ll resend as v2.___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] failsafe: console failsafe shell improvements
When running a failsafe shell on a console, job control was unavailable,
and ^C did not function correctly.
This change invokes console failsafe shells via `setsid`, making them
session leaders and allowing them to claim controlling terminals, which
makes job control function properly. To support this, the busybox
`setsid` utility is enabled. This has a minimal 149-byte size impact on
a test x86_64 squashfs rootfs image.
^C was causing console failsafe shell itself to exit, and was being
ignored in subprocesses of such shells: it was not possible to ^C out of
a program that would not exit on its own, such as many typical `ping`
invocations. As job control was unavailable, it was not possible to
suspend these subprocesses either, causing a hung program to tie up a
console indefinitely, unless another means to signal the program was
available. This was caused by SIGINT being placed at disposition SIG_IGN
by the shell running preinit, which it did because the console shell was
executed asynchronously with &. That disposition was inherited by the
console shell and its subprocesses, generally causing ^C to have no
effect. In the console shell itself, although SIGINT was ignored, ^C
caused the read loop to return with nothing read, which the shell
"converted" to SIGINT, causing it to exit.
As there is no way in busybox `ash` to reset the disposition of a signal
already ignored at shell entry, and no apparent way to avoid SIGINT
being placed at SIG_IGN when & is used in preinit, an alternative
construct is needed. Now, `start-stop-daemon` is used to start (-S) the
console failsafe shell in the background (-b). This approach does not
alter SIGINT, allowing the console shell to be started with that
signal's handling intact, and normal ^C processing to occur.
busybox `ash` has some behaviors conditional on SHLVL, and while the
console shells ought to run at SHLVL=1, they were not by virtue of being
started by the shell-based preinit system. Additionally, a variety of
detritus was present in the console shell's environment, carried over
from preinit. These conditions are corrected by running the console
shell via `env -i` to clear the environment and establish a minimum and
correct set of environment variables for operation, in the same manner
as `login`. HOME is not explicitly set, because it's addressed in
/etc/profile. For non-failsafe console shells when
system.@system[0].ttylogin = 0, `login -f root` achieves a similar
effect. (`login` already started non-failsafe console shells when
ttylogin = 1 and behaved correctly. This brings the ttylogin = 0 case to
parity.) Note that even `login -f` is somewhat undesirable for failsafe
shells because it requires a viable /etc/passwd, hence the `env -i`
construct in that case.
The TERM environment variable from the preinit environment, with value
"linux", would rarely be correct for serial consoles. Now, the preinit
TERM value is preserved (or set to "linux" if unset) only when the
console is /dev/console or /dev/tty[0-9]*. Otherwise, it will be set to
a safe default appropriate for serial consoles, "vt102". This change is
also duplicated for non-failsafe console shells.
This also indicates failsafe mode by showing "- failsafe -" on all
consoles (not just the last-defined one). It sets a hostname of
"OpenWrt-failsafe" in failsafe mode which is rendered in the shell's
prompt as a reminder of the mode during interactive failsafe use.
Previously, no hostname was set, which resulted in the kernel-default
hostname, "(none)", appearing in failsafe shell prompts.
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/10_indicate_failsafe | 7 ++-
.../files/lib/preinit/30_failsafe_wait | 5 -
.../files/lib/preinit/99_10_failsafe_login | 18 +-
package/base-files/files/usr/libexec/login.sh | 14 +-
package/utils/busybox/Config-defaults.in | 2 +-
5 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_failsafe
b/package/base-files/files/lib/preinit/10_indicate_failsafe
index 7bf5e029e42f..8c950bff74d0 100644
--- a/package/base-files/files/lib/preinit/10_indicate_failsafe
+++ b/package/base-files/files/lib/preinit/10_indicate_failsafe
@@ -9,9 +9,14 @@ indicate_failsafe_led () {
indicate_failsafe() {
[ "$pi_preinit_no_failsafe" = "y" ] && return
- echo "- failsafe -"
+ local consoles="$(cat /sys/class/tty/console/active)"
+ [ -n "$consoles" ] || consoles=console
+ for console in $consoles; do
+ [ -c "/dev/$console" ] && echo "- failsafe -" >"/dev/$console"
+ done
preinit_net_echo "Entering Failsafe!\n"
indicate_failsafe_led
+ echo OpenWrt-failsafe > /proc/sys/kernel/hostname
}
boot_ho
[PATCH] libmnl: fix build when bash is not located at /bin/bash
From: Mark Mentovai
This fixes the libmnl build on macOS, which ships with an outdated bash
at /bin/bash. During the OpenWrt build, a modern host bash is built and
made available at staging_dir/host/bin/bash, which is present before
/bin/bash in the build's PATH.
This is similar to 8f7ce3aa6dda, presently appearing at
package/kernel/mac80211/patches/build/001-fix_build.patch.
Signed-off-by: Mark Mentovai
---
package/libs/libmnl/patches/001-fix_build.patch | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 package/libs/libmnl/patches/001-fix_build.patch
diff --git a/package/libs/libmnl/patches/001-fix_build.patch
b/package/libs/libmnl/patches/001-fix_build.patch
new file mode 100644
index ..030020abacbe
--- /dev/null
+++ b/package/libs/libmnl/patches/001-fix_build.patch
@@ -0,0 +1,11 @@
+--- a/doxygen/Makefile.am
b/doxygen/Makefile.am
+@@ -21,7 +21,7 @@
+ # The command has to be a single line so the functions work
+ # and so `make` gives all lines to `bash -c`
+ # (hence ";\" at the end of every line but the last).
+- /bin/bash -p -c 'declare -A renamed_page;\
++ bash -p -c 'declare -A renamed_page;\
+ main(){ set -e; cd man/man3; rm -f _*;\
+ count_real_pages;\
+ rename_real_pages;\
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] failsafe: console failsafe shell improvements
When running a failsafe shell on a console, job control was unavailable,
and ^C did not function correctly.
This change invokes console failsafe shells via `setsid`, making them
session leaders and allowing them to claim controlling terminals, which
makes job control function properly. To support this, the busybox
`setsid` utility is enabled. This has a minimal 149-byte size impact on
a test x86_64 squashfs rootfs image.
^C was causing console failsafe shell itself to exit, and was being
ignored in subprocesses of such shells: it was not possible to ^C out of
a program that would not exit on its own, such as many typical `ping`
invocations. As job control was unavailable, it was not possible to
suspend these subprocesses either, causing a hung program to tie up a
console indefinitely, unless another means to signal the program was
available. This was caused by SIGINT being placed at disposition SIG_IGN
by the shell running preinit, which it did because the console shell was
executed asynchronously with &. That disposition was inherited by the
console shell and its subprocesses, generally causing ^C to have no
effect. In the console shell itself, although SIGINT was ignored, ^C
caused the read loop to return with nothing read, which the shell
"converted" to SIGINT, causing it to exit.
As there is no way in busybox `ash` to reset the disposition of a signal
already ignored at shell entry, and no apparent way to avoid SIGINT
being placed at SIG_IGN when & is used in preinit, an alternative
construct is needed. Now, `start-stop-daemon` is used to start (-S) the
console failsafe shell in the background (-b). This approach does not
alter SIGINT, allowing the console shell to be started with that
signal's handling intact, and normal ^C processing to occur.
busybox `ash` has some behaviors conditional on SHLVL, and while the
console shells ought to run at SHLVL=1, they were not by virtue of being
started by the shell-based preinit system. Additionally, a variety of
detritus was present in the console shell's environment, carried over
from preinit. These conditions are corrected by running the console
shell via `env -i` to clear the environment and establish a minimum and
correct set of environment variables for operation, in the same manner
as `login`. Note that HOME is not explicitly set, because it's addressed
in /etc/profile. This change is duplicated for non-failsafe console
shells when system.@system[0].ttylogin = 0. (`login` starts these shells
when ttylogin = 1 and already behaved correctly. This brings the
ttylogin = 0 case to parity.)
The TERM environment variable from the preinit environment, with value
"linux", would rarely be correct for serial consoles. Now, the preinit
TERM value is preserved (or set to "linux" if unset) only when the
console is /dev/console or /dev/tty[0-9]*. Otherwise, it will be set to
a safe default appropriate for serial consoles, "vt102". This change is
also duplicated for non-failsafe console shells.
This also indicates failsafe mode by showing "- failsafe -" on all
consoles (not just the last-defined one). It sets a hostname of
"OpenWrt-failsafe" in failsafe mode which is rendered in the shell's
prompt as a reminder of the mode during interactive failsafe use.
Previously, no hostname was set, which resulted in the kernel-default
hostname, "(none)", appearing in failsafe shell prompts.
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/10_indicate_failsafe | 7 ++-
.../files/lib/preinit/30_failsafe_wait | 5 -
.../files/lib/preinit/99_10_failsafe_login | 16 +++-
package/base-files/files/usr/libexec/login.sh| 14 +-
package/utils/busybox/Config-defaults.in | 2 +-
5 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_failsafe
b/package/base-files/files/lib/preinit/10_indicate_failsafe
index 7bf5e029e42f..8c950bff74d0 100644
--- a/package/base-files/files/lib/preinit/10_indicate_failsafe
+++ b/package/base-files/files/lib/preinit/10_indicate_failsafe
@@ -9,9 +9,14 @@ indicate_failsafe_led () {
indicate_failsafe() {
[ "$pi_preinit_no_failsafe" = "y" ] && return
- echo "- failsafe -"
+ local consoles="$(cat /sys/class/tty/console/active)"
+ [ -n "$consoles" ] || consoles=console
+ for console in $consoles; do
+ [ -c "/dev/$console" ] && echo "- failsafe -" >"/dev/$console"
+ done
preinit_net_echo "Entering Failsafe!\n"
indicate_failsafe_led
+ echo OpenWrt-failsafe > /proc/sys/kernel/hostname
}
boot_hook_add failsafe indicate_failsafe
diff --git a/package/base-files/files/lib/preinit/30_failsafe_wait
b/package/base-files/files/lib/preinit/30_failsafe_wait
ind
[PATCH] include/prereq-build.mk: macOS cross build improvements
This updates prereq-build.mk to find a suitable realpath utility, and adds another place to look for a suitable getopt utility. realpath has been used most notably by scripts/ipkg-build since bb95be9265a9e (2021-02-04), and there are assorted other uses of it during a build. It is ordinarily provided by GNU coreutils. This adds a SetupHostCommand to locate it either under its own name or under grealpath, the name that it will be available as under MacPorts or Homebrew, which use --program-prefix=g. Similarly, update the SetupHostCommand for getopt to be able to locate a util-linux getopt at the default path used by MacPorts, in the same fashion that cc16f5d73e770 (2020-11-14) did for Homebrew. As there is no standard alternative --program-prefix for util-linux utilities in the way that GNU packages often use a "g" prefix, this path-based approach is required in case a non-util-linux getopt (such as one provided by an OS) shadows the util-linux getopt in the PATH. Signed-off-by: Mark Mentovai --- include/prereq-build.mk | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index e1918f002787..1b7088456c27 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -130,7 +130,12 @@ $(eval $(call SetupHostCommand,getopt, \ Please install an extended getopt version that supports --long, \ gnugetopt -o t --long test -- --test | grep '^ *--test *--', \ getopt -o t --long test -- --test | grep '^ *--test *--', \ - /usr/local/opt/gnu-getopt/bin/getopt -o t --long test -- --test | grep '^ *--test *--')) + /usr/local/opt/gnu-getopt/bin/getopt -o t --long test -- --test | grep '^ *--test *--', \ + /opt/local/bin/getopt -o t --long test -- --test | grep '^ *--test *--')) + +$(eval $(call SetupHostCommand,realpath,Please install a 'realpath' utility, \ + grealpath /, \ + realpath /)) $(eval $(call SetupHostCommand,stat,Cannot find a file stat utility, \ gnustat -c%s $(TOPDIR)/Makefile, \ -- 2.36.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] failsafe: run on all consoles listed in /proc/cmdline
On x86, when both CONFIG_GRUB_CONSOLE and CONFIG_GRUB_SERIAL are set (as
they are by default), the kernel command line will have two console=
entries, such as
console=tty0 console=ttyS0,115200n8
Failsafe was only running a shell on the first defined console, the VGA
console. This is a problem for devices like apu2, where there is only a
serial console and it appears on ttyS0.
Moreover, the console prompt to enter failsafe during boot was delivered
to, and its input read from, the last console= on the kernel command
line. So while the failsafe shell was on the first defined console, only
the last defined console could be used to enter failsafe during boot.
In contrast, the x86 bootloader (GRUB) operates on both the serial
console and the VGA console by virtue of "terminal_{input,output}
console serial". GRUB also provided an alternate means to enter failsafe
from either console. The presence of two console= kernel command line
parameters causes kernel messages to be delivered to both. Under normal
operation (not failsafe), procd runs login in accordance with inittab,
which on x86 specifies ttyS0, hvc0, and tty1, allowing login through any
of serial, hypervisor, or VGA console. Thus, serial access was
consistently available on x86 devices with serial consoles under normal
operation, except for shell access in failsafe mode (without editing the
kernel command line).
By presenting the failsafe prompt, reading failsafe prompt input, and
running failsafe shells on all consoles listed in /proc/cmdline,
failsafe mode will work correctly on devices with a serial console (like
apu2), and the same image without any need for reconfiguration can be
shared by devices with the more traditional (for x86) VGA console. This
improvement should benefit any system with multiple console= arguments,
including x86 and bcm27xx (Raspberry Pi).
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/30_failsafe_wait| 60 ++-
.../files/lib/preinit/99_10_failsafe_login| 15 ++---
2 files changed, 40 insertions(+), 35 deletions(-)
diff --git a/package/base-files/files/lib/preinit/30_failsafe_wait
b/package/base-files/files/lib/preinit/30_failsafe_wait
index f90de71d40f2..9ab2e8bd4d8b 100644
--- a/package/base-files/files/lib/preinit/30_failsafe_wait
+++ b/package/base-files/files/lib/preinit/30_failsafe_wait
@@ -40,35 +40,39 @@ fs_wait_for_key () {
rm -f $keypress_wait
} &
- [ "$pi_preinit_no_failsafe" != "y" ] && echo "Press the [$1] key and
hit [enter] $2"
- echo "Press the [1], [2], [3] or [4] key and hit [enter] to select the
debug level"
- # if we're on the console we wait for input
- {
- while [ -r $keypress_wait ]; do
- timer="$(cat $keypress_sec)"
+ local consoles="$(sed -e 's/ /\n/g' /proc/cmdline | grep '^console=' |
sed -e 's/^console=//' -e 's/,.*//')"
+ [ -n "$consoles" ] || consoles=console
+ for console in $consoles; do
+ [ -c "/dev/$console" ] || continue
+ [ "$pi_preinit_no_failsafe" != "y" ] && echo "Press the [$1]
key and hit [enter] $2" > "/dev/$console"
+ echo "Press the [1], [2], [3] or [4] key and hit [enter] to
select the debug level" > "/dev/$console"
+ {
+ while [ -r $keypress_wait ]; do
+ timer="$(cat $keypress_sec)"
- [ -n "$timer" ] || timer=1
- timer="${timer%%\ *}"
- [ $timer -ge 1 ] || timer=1
- do_keypress=""
- {
- read -t "$timer" do_keypress
- case "$do_keypress" in
- $1)
- echo "true" >$keypress_true
- ;;
- 1 | 2 | 3 | 4)
- echo "$do_keypress" >/tmp/debug_level
- ;;
- *)
- continue;
- ;;
- esac
- lock -u $keypress_wait
- rm -f $keypress_wait
- }
- done
- }
+ [ -n "$timer" ] || timer=1
+ timer="${timer%%\ *}"
+ [ $timer -ge 1 ] || timer=1
+ do_keypress=""
+
[PATCH] failsafe: run on all consoles listed in /proc/cmdline
On x86, when both CONFIG_GRUB_CONSOLE and CONFIG_GRUB_SERIAL are set (as
they are by default), the kernel command line will have two console=
entries, such as
console=tty0 console=ttyS0,115200n8
Failsafe was only running a shell on the first defined console, the VGA
console. This is a problem for devices like apu2, where there is only a
serial console and it appears on ttyS0.
In contrast, the bootloader (GRUB) operates on both the serial console
and the VGA console by virtue of "terminal_{input,output} console
serial". The presence of two console= kernel command line parameters
causes kernel messages to be delivered to both. Under normal operation
(not failsafe), procd runs login in accordance with inittab, which on
x86 specifies ttyS0, hvc0, and tty1, allowing login through any of
serial, hypervisor, or VGA console. Thus, serial access was consistently
available on x86 devices with serial consoles under normal operation,
except for shell access in failsafe mode (without editing the kernel
command line).
By running shells on all consoles listed in /proc/cmdline, failsafe mode
will work correctly on devices with a serial console (like apu2), and
the same image without any need for reconfiguration can be shared by
devices with the more traditional (for x86) VGA console.
Signed-off-by: Mark Mentovai
---
.../files/lib/preinit/99_10_failsafe_login| 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/package/base-files/files/lib/preinit/99_10_failsafe_login
b/package/base-files/files/lib/preinit/99_10_failsafe_login
index 1410c5f0db5f..6f4af3f28b53 100644
--- a/package/base-files/files/lib/preinit/99_10_failsafe_login
+++ b/package/base-files/files/lib/preinit/99_10_failsafe_login
@@ -2,13 +2,14 @@
# Copyright (C) 2010 Vertical Communications
failsafe_shell() {
- local console="$(sed -e 's/ /\n/g' /proc/cmdline | grep '^console=' |
head -1 | sed -e 's/^console=//' -e 's/,.*//')"
- [ -n "$console" ] || console=console
- [ -c "/dev/$console" ] || return 0
- while true; do
- ash --login <"/dev/$console" >"/dev/$console" 2>"/dev/$console"
- sleep 1
- done &
+ local consoles="$(sed -e 's/ /\n/g' /proc/cmdline | grep '^console=' |
sed -e 's/^console=//' -e 's/,.*//')"
+ [ -n "$consoles" ] || consoles=console
+ for console in $consoles; do
+ [ -c "/dev/$console" ] && while true; do
+ ash --login <"/dev/$console" >"/dev/$console"
2>"/dev/$console"
+ sleep 1
+ done &
+ done
}
boot_hook_add failsafe failsafe_shell
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] hostapd: allow hostapd under ujail to communicate with hostapd_cli
When procd-ujail is available, 1f785383875a runs hostapd as user
"network", with only limited additional capabilities (CAP_NET_ADMIN and
CAP_NET_RAW).
hostapd_cli (CONFIG_PACKAGE_hostapd-utils) communicates with hostapd
over a named UNIX-domain socket. hostapd_cli is responsible for creating
this socket at /tmp/wpa_ctrl_$pid_$counter. Since it typically runs as
root, this endpoint is normally created with uid root, gid root, mode
0755. As a result, hostapd running as uid network is able to receive
control messages sent through this interface, but is not able to respond
to them. If debug-level logging is enabled (CONFIG_WPA_MSG_MIN_PRIORITY
<= 2 at build, and log_level <= 2 in /etc/config/wireless wifi-device),
this message will appear from hostapd:
CTRL: sendto failed: Permission denied
As a fix, hostapd_cli should create the socket node in the filesystem
with uid network, gid network, mode 0770. This borrows the presently
Android-only strategy already in hostapd intended to solve the same
problem on Android.
If procd-ujail is not available and hostapd falls back to running as
root, it will still be able to read from and write to the socket even if
the node in the filesystem has been restricted to the network user and
group. This matches the logic in
package/network/services/hostapd/files/wpad.init, which sets the uid and
gid of /var/run/hostapd to network regardless of whether procd-ujail is
available.
As it appears that the "network" user and group are statically allocated
uid 101 and gid 101, respectively, per
package/base-files/files/etc/passwd and USERID in
package/network/services/hostapd/Makefile, this patch also uses a
constant 101 for the uid and gid.
Cc: Daniel Golle
Signed-off-by: Mark Mentovai
---
.../610-hostapd_cli_ujail_permission.patch| 57 +++
1 file changed, 57 insertions(+)
create mode 100644
package/network/services/hostapd/patches/610-hostapd_cli_ujail_permission.patch
diff --git
a/package/network/services/hostapd/patches/610-hostapd_cli_ujail_permission.patch
b/package/network/services/hostapd/patches/610-hostapd_cli_ujail_permission.patch
new file mode 100644
index ..88a08e2aad0e
--- /dev/null
+++
b/package/network/services/hostapd/patches/610-hostapd_cli_ujail_permission.patch
@@ -0,0 +1,57 @@
+--- a/src/common/wpa_ctrl.c
b/src/common/wpa_ctrl.c
+@@ -130,29 +130,29 @@
+ (int) getpid(), counter);
+ }
+ if (os_snprintf_error(sizeof(ctrl->local.sun_path), ret)) {
+ close(ctrl->s);
+ os_free(ctrl);
+ return NULL;
+ }
+ tries++;
+-#ifdef ANDROID
++
+ /* Set client socket file permissions so that bind() creates the client
+* socket with these permissions and there is no need to try to change
+* them with chmod() after bind() which would have potential issues with
+* race conditions. These permissions are needed to make sure the server
+* side (wpa_supplicant or hostapd) can reply to the control interface
+* messages.
+*
+* The lchown() calls below after bind() are also part of the needed
+* operations to allow the response to go through. Those are using the
+* no-deference-symlinks version to avoid races. */
+ fchmod(ctrl->s, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
+-#endif /* ANDROID */
++
+ if (bind(ctrl->s, (struct sockaddr *) >local,
+ sizeof(ctrl->local)) < 0) {
+ if (errno == EADDRINUSE && tries < 2) {
+ /*
+* getpid() returns unique identifier for this instance
+* of wpa_ctrl, so the existing socket file must have
+* been left by unclean termination of an earlier run.
+* Remove the file and try again.
+@@ -160,17 +160,21 @@
+ unlink(ctrl->local.sun_path);
+ goto try_again;
+ }
+ close(ctrl->s);
+ os_free(ctrl);
+ return NULL;
+ }
+
+-#ifdef ANDROID
++#ifndef ANDROID
++ /* Set group even if we do not have privileges to change owner */
++ lchown(ctrl->local.sun_path, -1, 101);
++ lchown(ctrl->local.sun_path, 101, 101);
++#else
+ /* Set group even if we do not have privileges to change owner */
+ lchown(ctrl->local.sun_path, -1, AID_WIFI);
+ lchown(ctrl->local.sun_path, AID_SYSTEM, AID_WIFI);
+
+ if (os_strncmp(ctrl_path, "@android:", 9) == 0) {
+ if (socket_local_client_connect(
+ ctrl->s, ctrl_path + 9,
+ ANDROID_SOCKET_NAMESPACE_RESERVED,
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mediatek/ubnt, unifi-6-lr: fix ucidef network configuration typo
There's no such thing as ucidef_set_interfaces_lan. It's ucidef_set_interface_lan. Cc: David Bauer Signed-off-by: Mark Mentovai --- target/linux/mediatek/mt7622/base-files/etc/board.d/02_network | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network b/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network index 361d60e92b96..3724fd6d5c85 100644 --- a/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network +++ b/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network @@ -20,7 +20,7 @@ mediatek_setup_interfaces() ;; ubnt,unifi-6-lr|\ ubnt,unifi-6-lr-ubootmod) - ucidef_set_interfaces_lan "eth0" + ucidef_set_interface_lan "eth0" ;; *) ucidef_add_switch "switch0" \ -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] ipq806x: Bring missing patches from 5.4 to 5.10
Kernel 5.10 support for ipq806x was added at the same time that these
patches were developed for kernel 5.4. This carries the patches forward
to kernel 5.10.
fa731838c524 ipq806x: dwmac: clear forced speed during probe
75ca641f1b84 ipq806x: Add "snps,dwmac" to all gmac compatible=
d62825dd77b3 ipq806x: dwmac: set forced speed when using fixed-link
Signed-off-by: Mark Mentovai
Run-tested: ipq806x/ubnt,unifi-ac-hd
Cc: Ansuel Smith
---
.../082-ipq8064-dtsi-tweaks.patch | 36
...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 83 +++
2 files changed, 119 insertions(+)
create mode 100644
target/linux/ipq806x/patches-5.10/101-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
diff --git a/target/linux/ipq806x/patches-5.10/082-ipq8064-dtsi-tweaks.patch
b/target/linux/ipq806x/patches-5.10/082-ipq8064-dtsi-tweaks.patch
index b6e8e915eb5d..c91fb68dc425 100644
--- a/target/linux/ipq806x/patches-5.10/082-ipq8064-dtsi-tweaks.patch
+++ b/target/linux/ipq806x/patches-5.10/082-ipq8064-dtsi-tweaks.patch
@@ -141,6 +141,42 @@
};
tcsr: syscon@1a40 {
+@@ -622,7 +649,7 @@
+
+ gmac0: ethernet@3700 {
+ device_type = "network";
+- compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3700 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
+@@ -645,7 +672,7 @@
+
+ gmac1: ethernet@3720 {
+ device_type = "network";
+- compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3720 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
+@@ -668,7 +695,7 @@
+
+ gmac2: ethernet@3740 {
+ device_type = "network";
+- compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3740 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
+@@ -691,7 +718,7 @@
+
+ gmac3: ethernet@3760 {
+ device_type = "network";
+- compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3760 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
@@ -740,13 +767,13 @@
qcom,ee = <0>;
};
diff --git
a/target/linux/ipq806x/patches-5.10/101-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
b/target/linux/ipq806x/patches-5.10/101-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
new file mode 100644
index ..3c497ead6afc
--- /dev/null
+++
b/target/linux/ipq806x/patches-5.10/101-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
@@ -0,0 +1,83 @@
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c
+@@ -64,6 +64,17 @@
+ #define NSS_COMMON_CLK_DIV_SGMII_100 4
+ #define NSS_COMMON_CLK_DIV_SGMII_10 49
+
++#define QSGMII_PCS_ALL_CH_CTL 0x80
++#define QSGMII_PCS_CH_SPEED_FORCE 0x2
++#define QSGMII_PCS_CH_SPEED_100x0
++#define QSGMII_PCS_CH_SPEED_100 0x4
++#define QSGMII_PCS_CH_SPEED_1000 0x8
++#define QSGMII_PCS_CH_SPEED_MASK (QSGMII_PCS_CH_SPEED_FORCE | \
++ QSGMII_PCS_CH_SPEED_10 | \
++ QSGMII_PCS_CH_SPEED_100 | \
++ QSGMII_PCS_CH_SPEED_1000)
++#define QSGMII_PCS_CH_SPEED_SHIFT(x) (x * 4)
++
+ #define QSGMII_PCS_CAL_LCKDT_CTL 0x120
+ #define QSGMII_PCS_CAL_LCKDT_CTL_RST BIT(19)
+
+@@ -241,6 +252,36 @@ static void ipq806x_gmac_fix_mac_speed(v
+ ipq806x_gmac_set_speed(gmac, speed);
+ }
+
++static int
++ipq806x_gmac_get_qsgmii_pcs_speed_val(struct platform_device *pdev) {
++ struct device_node *fixed_link_node;
++ int rv;
++ int fixed_link_speed;
++
++ if (!of_phy_is_fixed_link(pdev->dev.of_node))
++ return 0;
++
++ fixed_link_node = of_get_child_by_name(pdev->dev.of_node, "fixed-link");
++ if (!fixed_link_node)
++ return -1;
++
++ rv = of_property_read_u32(fixed_link_node, "speed", _link_speed);
++ of_node_put(fixed_li
[PATCH 1/2] ipq806x: Add mising devices to kernel 5.10
d53be2a2e981 migrated 0069-arm-boot-add-dts-files.patch from patches-5.4 to patches-5.10, but a subsequent patch in that set, 1e25423be8ac, erroneously removed several devices: ipq8062/nec,wg2600hp3 from 3bb16185737c ipq8064/asrock,g10 from 98b86296e67d ipq8064/ubnt,unifi-ac-hd from 4e46beb31342 Signed-off-by: Mark Mentovai Run-tested: ipq806x/ubnt,unifi-ac-hd Cc: Ansuel Smith --- .../ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch b/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch index d5b1d4473bf0..2b069b8cfb40 100644 --- a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch +++ b/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch @@ -10,8 +10,11 @@ Signed-off-by: John Crispin --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile -@@ -909,6 +909,20 @@ dtb-$(CONFIG_ARCH_QCOM) += \ +@@ -907,8 +907,25 @@ + qcom-ipq4019-ap.dk04.1-c3.dtb \ + qcom-ipq4019-ap.dk07.1-c1.dtb \ qcom-ipq4019-ap.dk07.1-c2.dtb \ ++ qcom-ipq8062-wg2600hp3.dtb \ qcom-ipq8064-ap148.dtb \ qcom-ipq8064-rb3011.dtb \ + qcom-ipq8064-c2600.dtb \ @@ -20,8 +23,10 @@ Signed-off-by: John Crispin + qcom-ipq8064-ap161.dtb \ + qcom-ipq8064-ea7500-v1.dtb \ + qcom-ipq8064-ea8500.dtb \ ++ qcom-ipq8064-g10.dtb \ + qcom-ipq8064-r7500.dtb \ + qcom-ipq8064-r7500v2.dtb \ ++ qcom-ipq8064-unifi-ac-hd.dtb \ + qcom-ipq8064-wg2600hp.dtb \ + qcom-ipq8064-wpq864.dtb \ + qcom-ipq8064-wxr-2533dhp.dtb \ -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq806x: dwmac: fix GMACs connected via SGMII fixed-link
Ansuel Smith wrote: Tested-by: Ansuel Smith I also tested this with the qca8k driver on 5.10. Also can you include this with kernel 5.10 Yes, thanks. The broken fa731838c524 hasn't made it into patches-5.10 yet, so I'm going to merge this patch, that one, and 75ca641f1b84 into an update for patches-5.10 separately once I've had a chance to build and test. Mark ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipq806x: dwmac: fix GMACs connected via SGMII fixed-link
fa731838c524 cleared the forced speed in the QSGMII PCS_ALL_CH_CTL
register during probe, but this is only correct for GMACs that are not
configured with fixed-link. This prevented GMACs configured with both
phy-mode = "sgmii" and fixed-link from working properly, as discussed at
https://github.com/openwrt/openwrt/pull/3954#issuecomment-834625090 and
the comments that follow. Notably, this prevented all communication
between gmac2 and the switch on the Netgear R7800.
The correct behavior is to set the QSGMII PCS_ALL_CH_CTL register by
considering the gmac's fixed-link child, setting the speed as directed by
fixed-link if present, and otherwise clearing it as was done previously.
Fixes: fa731838c524 ("ipq806x: dwmac: clear forced speed during probe")
Signed-off-by: Mark Mentovai
Tested-by: Hannu Nyman
Run-tested: ipq806x/ubnt,unifi-ac-hd, ipq806x/netgear,r7800
Cc: Petr Štetiar
Cc: Ansuel Smith
---
...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 62 +--
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git
a/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
b/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
index 6cdbf4d3dc6b..3c497ead6afc 100644
---
a/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
+++
b/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch
@@ -18,16 +18,66 @@
#define QSGMII_PCS_CAL_LCKDT_CTL 0x120
#define QSGMII_PCS_CAL_LCKDT_CTL_RST BIT(19)
-@@ -345,6 +356,12 @@ static int ipq806x_gmac_probe(struct pla
+@@ -241,6 +252,36 @@ static void ipq806x_gmac_fix_mac_speed(v
+ ipq806x_gmac_set_speed(gmac, speed);
+ }
+
++static int
++ipq806x_gmac_get_qsgmii_pcs_speed_val(struct platform_device *pdev) {
++ struct device_node *fixed_link_node;
++ int rv;
++ int fixed_link_speed;
++
++ if (!of_phy_is_fixed_link(pdev->dev.of_node))
++ return 0;
++
++ fixed_link_node = of_get_child_by_name(pdev->dev.of_node, "fixed-link");
++ if (!fixed_link_node)
++ return -1;
++
++ rv = of_property_read_u32(fixed_link_node, "speed", _link_speed);
++ of_node_put(fixed_link_node);
++ if (rv)
++ return -1;
++
++ switch (fixed_link_speed) {
++ case SPEED_1000:
++ return QSGMII_PCS_CH_SPEED_FORCE | QSGMII_PCS_CH_SPEED_1000;
++ case SPEED_100:
++ return QSGMII_PCS_CH_SPEED_FORCE | QSGMII_PCS_CH_SPEED_100;
++ case SPEED_10:
++ return QSGMII_PCS_CH_SPEED_FORCE | QSGMII_PCS_CH_SPEED_10;
++ }
++
++ return -1;
++}
++
+ static int ipq806x_gmac_probe(struct platform_device *pdev)
+ {
+ struct plat_stmmacenet_data *plat_dat;
+@@ -249,6 +290,7 @@ static int ipq806x_gmac_probe(struct pla
+ struct ipq806x_gmac *gmac;
+ int val;
+ int err;
++ int qsgmii_pcs_speed;
+
+ val = stmmac_get_platform_resources(pdev, _res);
+ if (val)
+@@ -345,6 +387,17 @@ static int ipq806x_gmac_probe(struct pla
0x1ul << QSGMII_PHY_RX_INPUT_EQU_OFFSET |
0x2ul << QSGMII_PHY_CDR_PI_SLEW_OFFSET |
0xCul << QSGMII_PHY_TX_DRV_AMP_OFFSET);
+
-+ regmap_update_bits(gmac->qsgmii_csr,
-+ QSGMII_PCS_ALL_CH_CTL,
-+ QSGMII_PCS_CH_SPEED_MASK <<
-+ QSGMII_PCS_CH_SPEED_SHIFT(gmac->id),
-+ 0);
++ qsgmii_pcs_speed = ipq806x_gmac_get_qsgmii_pcs_speed_val(pdev);
++ if (qsgmii_pcs_speed != -1) {
++ regmap_update_bits(
++ gmac->qsgmii_csr,
++ QSGMII_PCS_ALL_CH_CTL,
++ QSGMII_PCS_CH_SPEED_MASK <<
++ QSGMII_PCS_CH_SPEED_SHIFT(gmac->id),
++ qsgmii_pcs_speed <<
++ QSGMII_PCS_CH_SPEED_SHIFT(gmac->id));
++ }
}
plat_dat->has_gmac = true;
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipq806x: Add "snps,dwmac" to all gmac compatible=
This was introduced to gmac2 and gmac3 in 57ea767a53c1 without fanfare.
There's no indication of why it was added to those devices, but not to
gmac0 or gmac1. It was probably an unintentional omission. It should be
present on all four gmac devices.
This property is considered by
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
stmmac_probe_config_dt.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
b/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
index 221ecd73965a..cbb0231d43ea 100644
--- a/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
+++ b/target/linux/ipq806x/patches-5.4/083-ipq8064-dtsi-additions.patch
@@ -879,7 +879,7 @@
+
+ gmac0: ethernet@3700 {
+ device_type = "network";
-+ compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3700 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
@@ -902,7 +902,7 @@
+
+ gmac1: ethernet@3720 {
+ device_type = "network";
-+ compatible = "qcom,ipq806x-gmac";
++ compatible = "qcom,ipq806x-gmac", "snps,dwmac";
+ reg = <0x3720 0x20>;
+ interrupts = ;
+ interrupt-names = "macirq";
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] ipq806x: dwmac: clear forced speed during probe
On a Ubiquiti UniFi AC HD (ubnt,unifi-ac-hd, UAP-AC-HD, UAP301), a forced speed on gmac1 is set in the QSGMII PCS_ALL_CH_CTL register, presumably by the bootloader (4.3.28), preventing the interface from being usable. The QSDK NSS GMAC driver takes care to clear the forced speed in nss_gmac_qsgmii_dev_init (https://source.codeaurora.org/quic/qsdk/oss/lklm/nss-gmac/tree/ipq806x/nss_gmac_init.c?h=nss at d5bb14925861). gmac1 is connected to the port on the device labeled SECONDARY, and is currently eth0 but will be switched to eth1 by a subsequent patch. By clearing the QSGMII PCS forced speed during dwmac initialization when SGMII is in use, this port becomes usable. This patch is upstreamable, and will be sent upstream after successful testing in OpenWrt. Signed-off-by: Mark Mentovai Build-tested: ipq806x/ubnt,unifi-ac-hd Run-tested: ipq806x/ubnt,unifi-ac-hd --- ...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 33 +++ 1 file changed, 33 insertions(+) create mode 100644 target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch diff --git a/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch b/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch new file mode 100644 index ..6cdbf4d3dc6b --- /dev/null +++ b/target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch @@ -0,0 +1,33 @@ +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c +@@ -64,6 +64,17 @@ + #define NSS_COMMON_CLK_DIV_SGMII_100 4 + #define NSS_COMMON_CLK_DIV_SGMII_10 49 + ++#define QSGMII_PCS_ALL_CH_CTL 0x80 ++#define QSGMII_PCS_CH_SPEED_FORCE 0x2 ++#define QSGMII_PCS_CH_SPEED_100x0 ++#define QSGMII_PCS_CH_SPEED_100 0x4 ++#define QSGMII_PCS_CH_SPEED_1000 0x8 ++#define QSGMII_PCS_CH_SPEED_MASK (QSGMII_PCS_CH_SPEED_FORCE | \ ++ QSGMII_PCS_CH_SPEED_10 | \ ++ QSGMII_PCS_CH_SPEED_100 | \ ++ QSGMII_PCS_CH_SPEED_1000) ++#define QSGMII_PCS_CH_SPEED_SHIFT(x) (x * 4) ++ + #define QSGMII_PCS_CAL_LCKDT_CTL 0x120 + #define QSGMII_PCS_CAL_LCKDT_CTL_RST BIT(19) + +@@ -345,6 +356,12 @@ static int ipq806x_gmac_probe(struct pla +0x1ul << QSGMII_PHY_RX_INPUT_EQU_OFFSET | +0x2ul << QSGMII_PHY_CDR_PI_SLEW_OFFSET | +0xCul << QSGMII_PHY_TX_DRV_AMP_OFFSET); ++ ++ regmap_update_bits(gmac->qsgmii_csr, ++ QSGMII_PCS_ALL_CH_CTL, ++ QSGMII_PCS_CH_SPEED_MASK << ++ QSGMII_PCS_CH_SPEED_SHIFT(gmac->id), ++ 0); + } + + plat_dat->has_gmac = true; -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] ipq806x: ubnt,unifi-ac-hd: use on-board PHYs
Unlike many ipq806x devices, Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301)
has no switch on board. Its two Ethernet ports are connected to Atheros
AR8033 PHYs. It is not appropriate to use fixed-link in this
configuration. Instead, configure the correct PHYs in the device tree
configuration to allow the at803x driver to load.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
index 7c2d6c9d1307..70c51b90f316 100644
--- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
@@ -16,6 +16,8 @@
led-running = _dome_blue;
led-upgrade = _dome_blue;
mdio-gpio0 =
+ ethernet0 =
+ ethernet1 =
};
leds {
@@ -229,38 +231,36 @@
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-};
-
- {
- status = "okay";
- phy-mode = "sgmii";
- qcom,id = <2>;
- qcom,emulation = <0>;
- mdiobus = <>;
-
- mtd-mac-address = < 0x0>;
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
- fixed-link {
- speed = <1000>;
- full-duplex;
+ phy5: ethernet-phy@5 {
+ reg = <5>;
};
};
{
status = "okay";
+ mdiobus = <>;
+ phy-handle = <>;
phy-mode = "sgmii";
qcom,id = <1>;
- qcom,emulation = <0>;
- mdiobus = <>;
mtd-mac-address = < 0x6>;
+};
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
+ {
+ status = "okay";
+
+ mdiobus = <>;
+ phy-handle = <>;
+ phy-mode = "sgmii";
+ qcom,id = <2>;
+
+ mtd-mac-address = < 0x0>;
};
{
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] ipq806x: ubnt,unifi-ac-hd: reorder eth0 and eth1
The Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301) has two Ethernet ports,
labeled MAIN and SECONDARY, connected to gmac2 and gmac1, respectively.
The standard probe order results in gmac1/SECONDARY being eth0 and
gmac2/MAIN being eth1. This does not match the stock firmware, is
contrary to user expectation, causes the wrong (high) MAC address to be
used in a bridged configuration (the default for this device), and makes
the gmac2/MAIN port unusable in the preinit environment (such as for
failsafe). Until a recent patch, gmac1/SECONDARY (eth0) was not even
usable.
This reorders the ports so that gmac2/MAIN is eth0, and the now-working
gmac1/SECONDARY is eth1. eth0 has the low MAC address and eth1 has the
high; when bridged, the bridge takes on the correct low MAC address.
This matches the stock firmware. The MAIN port is usable for failsafe
during preinit.
This device does not have a switch on board, so there's no possibility
to remap ports via switch configuration. "ip link set $interface name"
is used instead, during preinit before networking is configured.
Signed-off-by: Mark Mentovai
Build-tested: ipq806x/ubnt,unifi-ac-hd
Run-tested: ipq806x/ubnt,unifi-ac-hd
---
.../ipq806x/base-files/lib/preinit/04_reorder_eth | 13 +
.../arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts | 4 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
diff --git a/target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
b/target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
new file mode 100644
index ..9f58473617dc
--- /dev/null
+++ b/target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth
@@ -0,0 +1,13 @@
+. /lib/functions.sh
+
+preinit_reorder_eth() {
+ case $(board_name) in
+ ubnt,unifi-ac-hd)
+ ip link set eth0 name ethtmp
+ ip link set eth1 name eth0
+ ip link set ethtmp name eth1
+ ;;
+ esac
+}
+
+boot_hook_add preinit_main preinit_reorder_eth
diff --git
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
index 70c51b90f316..672be3ca2c97 100644
--- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts
@@ -16,8 +16,8 @@
led-running = _dome_blue;
led-upgrade = _dome_blue;
mdio-gpio0 =
- ethernet0 =
- ethernet1 =
+ ethernet0 =
+ ethernet1 =
};
leds {
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/3] ipq806x: ubnt,unifi-ac-hd: fix Ethernet ports
The Ubiquiti UniFi AC HD (UAP-AC-HD, UAP301) has two Ethernet ports, labeled MAIN and SECONDARY, connected to gmac2 and gmac1, respectively. A dwmac register misconfiguration (QSGMII PCS_ALL_CH_CTL) for gmac1/SECONDARY prevented that port from being usable in OpenWrt. This patch series: - correctly configures that register, - properly configures the on-board PHYs for both interfaces, and - reorders eth0 and eth1 so that gmac2/MAIN is eth0 and gmac1/SECONDARY is eth1. Mark Mentovai (3): ipq806x: dwmac: clear forced speed during probe ipq806x: ubnt,unifi-ac-hd: use on-board PHYs ipq806x: ubnt,unifi-ac-hd: reorder eth0 and eth1 .../base-files/lib/preinit/04_reorder_eth | 13 +++ .../arm/boot/dts/qcom-ipq8064-unifi-ac-hd.dts | 38 +-- ...-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch | 33 3 files changed, 65 insertions(+), 19 deletions(-) create mode 100644 target/linux/ipq806x/base-files/lib/preinit/04_reorder_eth create mode 100644 target/linux/ipq806x/patches-5.4/100-dwmac-ipq806x-qsgmii-pcs-all-ch-ctl.patch -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Firmware loading in user space via hotplug (procd) is racy, radios don’t come up at first boot
User-space firmware loading is handled by hotplug in procd. It’s directed
by /etc/hotplug.json. Paraphrasing:
[
[ "case", "ACTION", {
"add": [
[ "if",
[ "has", "FIRMWARE" ],
[
[ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ],
[ "load-firmware", "/lib/firmware" ],
[ "return" ]
]
]
],
} ],
]
hotplug-call is responsible for locating the correct firmware and placing
it in /lib/firmware. load-firmware instructs hotplug to feed the firmware
from /lib/firmware to the kernel via the appropriate protocol.
There’s no synchronization between the hotplug-call exec and load-firmware
actions, so they’re effectively done in parallel. A long-running
hotplug-call is sure to be missed by load-firmware.
I discovered this in an ath79 build for Netgear WNDR3x00 (3700, 3700v2,
3800) devices. At first boot following a sysupgrade, the radios don’t come
up, although they’re functional on subsequent boots. Calibration data for
the radios is requested by owl-loader via the firmware mechanism.
/etc/hotplug.d/firmware/10-ath9k-eeprom is able to pull it out of the art
MTD partition, but this is fairly time-consuming on first boot, taking
around 15 seconds of wall clock time. 10-ath9k-eeprom does eventually place
a file in /lib/firmware where it’s usable on subsequent boots, but this
isn’t finished until well after the load-firmware action runs (and doesn’t
find any firmware).
As a local workaround, for now, I’ve gotten rid of the load-firmware action
and replaced hotplug-call with another script that runs hotplug-call and
then, in sequence, follows the firmware protocol itself. This works well
(although it’s still somewhat troubling that it takes 15 seconds per radio
to read less than 4kB each from art) but it strikes me that it just papers
over a procd bug.
Is there any reason that procd doesn’t waitpid() for hotplug-call before
advancing to load-firmware? It seems like a problem that load-firmware
doesn’t wait for an exec that precedes it. As it stands now, it’s likely
that when load-firmware runs, firmware either won’t be present or will only
have been partially written to /lib/firmware.
ath79 relies much more heavily on the firmware loading mechanism for
calibration data, where ar71xx handled it very differently. I expect that
this affects a number of other ath79 devices, as well as devices on other
platforms that rely on hotplug-call to locate firmware.
Mark
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] busybox: Update config for 1.24.1
Felix, is this patch acceptable? The v2 that made it to Patchwork applies cleanly to the trunk without any whitespace problems. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox: Update config for 1.24.1
Felix Fietkau wrote: > On 2015-11-21 22:43, Mark Mentovai wrote: > > r47288 updated to Busybox 1.24.1 but did not update the configuration. > > > > The configuration is updated by running > > > > cd config > > ../convert_menuconfig.pl .../build_dir/target-*/busybox-1.24.1 > > cd .. > > ./convert_defaults.pl < .../build_dir/target-*/busybox-1.24.1/.config > > \ > > Config-defaults.in > > > > Signed-off-by: Mark Mentovai <m...@moxienet.com> > Somehow lots of extra white space characters crept in, and this patch > does not apply. Please resend and consider using git send-email > I don’t know how that happened, that Alpine config used to work properly. I re-sent it as v2. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] busybox: Update config for 1.24.1
r47288 updated to Busybox 1.24.1 but did not update the configuration. The configuration is updated by running cd config ../convert_menuconfig.pl .../build_dir/target-*/busybox-1.24.1 cd .. ./convert_defaults.pl < .../build_dir/target-*/busybox-1.24.1/.config > \ Config-defaults.in Signed-off-by: Mark Mentovai <m...@moxienet.com> --- package/utils/busybox/Config-defaults.in | 159 +++--- package/utils/busybox/config/archival/Config.in | 10 ++ package/utils/busybox/config/coreutils/Config.in | 116 +++-- package/utils/busybox/config/miscutils/Config.in | 36 + package/utils/busybox/config/networking/Config.in | 135 +++- package/utils/busybox/config/selinux/Config.in| 2 +- package/utils/busybox/config/util-linux/Config.in | 189 -- 7 files changed, 412 insertions(+), 235 deletions(-) diff --git a/package/utils/busybox/Config-defaults.in b/package/utils/busybox/Config-defaults.in index 2689b4f71aeb..75c59760c3b6 100644 --- a/package/utils/busybox/Config-defaults.in +++ b/package/utils/busybox/Config-defaults.in @@ -361,6 +361,9 @@ config BUSYBOX_DEFAULT_FEATURE_GZIP_LONG_OPTIONS config BUSYBOX_DEFAULT_GZIP_FAST int default 0 +config BUSYBOX_DEFAULT_FEATURE_GZIP_LEVELS + bool + default n config BUSYBOX_DEFAULT_LZOP bool default n @@ -430,6 +433,21 @@ config BUSYBOX_DEFAULT_FEATURE_DATE_NANO config BUSYBOX_DEFAULT_FEATURE_DATE_COMPAT bool default n +config BUSYBOX_DEFAULT_DD + bool + default y +config BUSYBOX_DEFAULT_FEATURE_DD_SIGNAL_HANDLING + bool + default y +config BUSYBOX_DEFAULT_FEATURE_DD_THIRD_STATUS_LINE + bool + default n +config BUSYBOX_DEFAULT_FEATURE_DD_IBS_OBS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_DD_STATUS + bool + default n config BUSYBOX_DEFAULT_HOSTID bool default n @@ -442,6 +460,12 @@ config BUSYBOX_DEFAULT_GROUPS config BUSYBOX_DEFAULT_SHUF bool default n +config BUSYBOX_DEFAULT_SYNC + bool + default y +config BUSYBOX_DEFAULT_FEATURE_SYNC_FANCY + bool + default n config BUSYBOX_DEFAULT_TEST bool default y @@ -466,6 +490,9 @@ config BUSYBOX_DEFAULT_FEATURE_TR_CLASSES config BUSYBOX_DEFAULT_FEATURE_TR_EQUIV bool default n +config BUSYBOX_DEFAULT_TRUNCATE + bool + default n config BUSYBOX_DEFAULT_UNLINK bool default n @@ -514,18 +541,6 @@ config BUSYBOX_DEFAULT_FEATURE_CP_LONG_OPTIONS config BUSYBOX_DEFAULT_CUT bool default y -config BUSYBOX_DEFAULT_DD - bool - default y -config BUSYBOX_DEFAULT_FEATURE_DD_SIGNAL_HANDLING - bool - default y -config BUSYBOX_DEFAULT_FEATURE_DD_THIRD_STATUS_LINE - bool - default n -config BUSYBOX_DEFAULT_FEATURE_DD_IBS_OBS - bool - default y config BUSYBOX_DEFAULT_DF bool default y @@ -730,9 +745,6 @@ config BUSYBOX_DEFAULT_STTY config BUSYBOX_DEFAULT_SUM bool default n -config BUSYBOX_DEFAULT_SYNC - bool - default y config BUSYBOX_DEFAULT_TAC bool default n @@ -757,6 +769,9 @@ config BUSYBOX_DEFAULT_TTY config BUSYBOX_DEFAULT_UNAME bool default y +config BUSYBOX_DEFAULT_UNAME_OSNAME + string + default "GNU/Linux" config BUSYBOX_DEFAULT_UNEXPAND bool default n @@ -1348,9 +1363,42 @@ config BUSYBOX_DEFAULT_FEATURE_MDEV_EXEC config BUSYBOX_DEFAULT_FEATURE_MDEV_LOAD_FIRMWARE bool default n +config BUSYBOX_DEFAULT_MOUNT + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_FAKE + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_VERBOSE + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_HELPERS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_LABEL + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_NFS + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_CIFS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_FLAGS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_FSTAB + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_OTHERTAB + bool + default n config BUSYBOX_DEFAULT_REV bool default n +config BUSYBOX_DEFAULT_UEVENT + bool + default n config BUSYBOX_DEFAULT_ACPID bool default n @@ -1486,33 +1534,6 @@ config BUSYBOX_DEFAULT_FEATURE_MKSWAP_UUID config BUSYBOX_DEFAULT_MORE bool default n -config BUSYBOX_DEFAULT_MOUNT - bool - default y -config BUSYBOX_DEFAULT_FEATURE_MOUNT_FAKE - bool - default n -config BUSYBOX_DEFAULT_FEATURE_MOUNT_VERBOSE - bool - default n -config BUSYBOX_DEFAULT_FEATURE_MOUNT_HELPERS - bool -
[OpenWrt-Devel] [PATCH] Fix Busybox “uname -o”
Since r47288, “uname -o” shows “n”. It used to be “GNU/Linux”. root@gw1 sh# uname -a Linux gw1.nyc 4.1.11 #1 Sat Nov 21 12:50:41 EST 2015 mips n root@gw1 sh# uname -o n It looks like a recent change in Busybox uname made “uname -o” configurable: http://git.busybox.net/busybox/commit?id=64ed5f0d3c5eefbb208d4a334654834c78be2cbd . In build_dir/target-mips_34kc_musl-1.1.11/busybox-1.24.1/.config, I see CONFIG_UNAME_OSNAME="n" Probably relevant, I use CONFIG_BUSYBOX_CUSTOM=y. OpenWrt’s busybox/config/coreutils/Config.in needs to mirror Busybox’ own coreutils/Config.src. Likely, all of OpenWrt’s busybox Config.in files need to be updated in this way after a Busybox update. Signed-off-by: Mark Mentovai <m...@moxienet.com> diff --git a/package/utils/busybox/config/coreutils/Config.in b/package/utils/busybox/config/coreutils/Config.in index f50823f012de..e25da6519f2b 100644 --- a/package/utils/busybox/config/coreutils/Config.in +++ b/package/utils/busybox/config/coreutils/Config.in @@ -829,6 +829,14 @@ config BUSYBOX_CONFIG_UNAME help uname is used to print system information. +config BUSYBOX_CONFIG_UNAME_OSNAME + string "Operating system name" + default "GNU/Linux" + depends on BUSYBOX_CONFIG_UNAME + help + Sets the operating system name reported by uname -o. The + default is "GNU/Linux". + config BUSYBOX_CONFIG_UNEXPAND bool "unexpand" default BUSYBOX_DEFAULT_UNEXPAND ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Fix Busybox “uname -o”
John Crispin wrote: patch does not apply to current trunk Sorry, the tabs got swallowed. I re-sent it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] busybox: Update config for 1.24.1
r47288 updated to Busybox 1.24.1 but did not update the configuration. The configuration is updated by running cd config ../convert_menuconfig.pl .../build_dir/target-*/busybox-1.24.1 cd .. ./convert_defaults.pl < .../build_dir/target-*/busybox-1.24.1/.config > \ Config-defaults.in Signed-off-by: Mark Mentovai <m...@moxienet.com> --- package/utils/busybox/Config-defaults.in | 159 +++--- package/utils/busybox/config/archival/Config.in | 10 ++ package/utils/busybox/config/coreutils/Config.in | 116 +++-- package/utils/busybox/config/miscutils/Config.in | 36 + package/utils/busybox/config/networking/Config.in | 135 +++- package/utils/busybox/config/selinux/Config.in| 2 +- package/utils/busybox/config/util-linux/Config.in | 189 -- 7 files changed, 412 insertions(+), 235 deletions(-) diff --git a/package/utils/busybox/Config-defaults.in b/package/utils/busybox/Config-defaults.in index 2689b4f71aeb..75c59760c3b6 100644 --- a/package/utils/busybox/Config-defaults.in +++ b/package/utils/busybox/Config-defaults.in @@ -361,6 +361,9 @@ config BUSYBOX_DEFAULT_FEATURE_GZIP_LONG_OPTIONS config BUSYBOX_DEFAULT_GZIP_FAST int default 0 +config BUSYBOX_DEFAULT_FEATURE_GZIP_LEVELS + bool + default n config BUSYBOX_DEFAULT_LZOP bool default n @@ -430,6 +433,21 @@ config BUSYBOX_DEFAULT_FEATURE_DATE_NANO config BUSYBOX_DEFAULT_FEATURE_DATE_COMPAT bool default n +config BUSYBOX_DEFAULT_DD + bool + default y +config BUSYBOX_DEFAULT_FEATURE_DD_SIGNAL_HANDLING + bool + default y +config BUSYBOX_DEFAULT_FEATURE_DD_THIRD_STATUS_LINE + bool + default n +config BUSYBOX_DEFAULT_FEATURE_DD_IBS_OBS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_DD_STATUS + bool + default n config BUSYBOX_DEFAULT_HOSTID bool default n @@ -442,6 +460,12 @@ config BUSYBOX_DEFAULT_GROUPS config BUSYBOX_DEFAULT_SHUF bool default n +config BUSYBOX_DEFAULT_SYNC + bool + default y +config BUSYBOX_DEFAULT_FEATURE_SYNC_FANCY + bool + default n config BUSYBOX_DEFAULT_TEST bool default y @@ -466,6 +490,9 @@ config BUSYBOX_DEFAULT_FEATURE_TR_CLASSES config BUSYBOX_DEFAULT_FEATURE_TR_EQUIV bool default n +config BUSYBOX_DEFAULT_TRUNCATE + bool + default n config BUSYBOX_DEFAULT_UNLINK bool default n @@ -514,18 +541,6 @@ config BUSYBOX_DEFAULT_FEATURE_CP_LONG_OPTIONS config BUSYBOX_DEFAULT_CUT bool default y -config BUSYBOX_DEFAULT_DD - bool - default y -config BUSYBOX_DEFAULT_FEATURE_DD_SIGNAL_HANDLING - bool - default y -config BUSYBOX_DEFAULT_FEATURE_DD_THIRD_STATUS_LINE - bool - default n -config BUSYBOX_DEFAULT_FEATURE_DD_IBS_OBS - bool - default y config BUSYBOX_DEFAULT_DF bool default y @@ -730,9 +745,6 @@ config BUSYBOX_DEFAULT_STTY config BUSYBOX_DEFAULT_SUM bool default n -config BUSYBOX_DEFAULT_SYNC - bool - default y config BUSYBOX_DEFAULT_TAC bool default n @@ -757,6 +769,9 @@ config BUSYBOX_DEFAULT_TTY config BUSYBOX_DEFAULT_UNAME bool default y +config BUSYBOX_DEFAULT_UNAME_OSNAME + string + default "GNU/Linux" config BUSYBOX_DEFAULT_UNEXPAND bool default n @@ -1348,9 +1363,42 @@ config BUSYBOX_DEFAULT_FEATURE_MDEV_EXEC config BUSYBOX_DEFAULT_FEATURE_MDEV_LOAD_FIRMWARE bool default n +config BUSYBOX_DEFAULT_MOUNT + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_FAKE + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_VERBOSE + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_HELPERS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_LABEL + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_NFS + bool + default n +config BUSYBOX_DEFAULT_FEATURE_MOUNT_CIFS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_FLAGS + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_FSTAB + bool + default y +config BUSYBOX_DEFAULT_FEATURE_MOUNT_OTHERTAB + bool + default n config BUSYBOX_DEFAULT_REV bool default n +config BUSYBOX_DEFAULT_UEVENT + bool + default n config BUSYBOX_DEFAULT_ACPID bool default n @@ -1486,33 +1534,6 @@ config BUSYBOX_DEFAULT_FEATURE_MKSWAP_UUID config BUSYBOX_DEFAULT_MORE bool default n -config BUSYBOX_DEFAULT_MOUNT - bool - default y -config BUSYBOX_DEFAULT_FEATURE_MOUNT_FAKE - bool - default n -config BUSYBOX_DEFAULT_FEATURE_MOUNT_VERBOSE - bool - default n -config BUSYBOX_DEFAULT_FEATURE_MOUNT_HELPERS - bool -
[OpenWrt-Devel] [PATCH v2] Fix Busybox “uname -o”
Since r47288, “uname -o” shows “n”. It used to be “GNU/Linux”. root at gw1 sh# uname -a Linux gw1.nyc 4.1.11 #1 Sat Nov 21 12:50:41 EST 2015 mips n root at gw1 sh# uname -o n It looks like a recent change in Busybox uname made “uname -o” configurable: http://git.busybox.net/busybox/commit?id=64ed5f0d3c5eefbb208d4a334654834c78be2cbd. In build_dir/target-mips_34kc_musl-1.1.11/busybox-1.24.1/.config, I see CONFIG_UNAME_OSNAME="n" Probably relevant, I use CONFIG_BUSYBOX_CUSTOM=y. OpenWrt’s busybox/config/coreutils/Config.in needs to mirror Busybox’ own coreutils/Config.src. Likely, all of OpenWrt’s busybox Config.in files need to be updated in this way after a Busybox update. Signed-off-by: Mark Mentovai <m...@moxienet.com> diff --git a/package/utils/busybox/config/coreutils/Config.in b/package/utils/busybox/config/coreutils/Config.in index f50823f012de..e25da6519f2b 100644 --- a/package/utils/busybox/config/coreutils/Config.in +++ b/package/utils/busybox/config/coreutils/Config.in @@ -829,6 +829,14 @@ config BUSYBOX_CONFIG_UNAME help uname is used to print system information. +config BUSYBOX_CONFIG_UNAME_OSNAME + string "Operating system name" + default "GNU/Linux" + depends on BUSYBOX_CONFIG_UNAME + help + Sets the operating system name reported by uname -o. The + default is "GNU/Linux". + config BUSYBOX_CONFIG_UNEXPAND bool "unexpand" default BUSYBOX_DEFAULT_UNEXPAND___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] Fix Busybox “uname -o”
I wrote: OpenWrt’s busybox/config/coreutils/Config.in needs to mirror Busybox’ own coreutils/Config.src. Likely, all of OpenWrt’s busybox Config.in files need to be updated in this way after a Busybox update. I posted this as an alternative, more complete patch, under the title [PATCH] busybox: Update config for 1.24.1.___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uci -P no longer working correctly
Yousong Zhou wrote: I just sent a patch for this with you in the cc list. Could you give it a try and tell if it can work for you? Thanks, Yousong. Your patch fixes this for me. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uci -P no longer working correctly
In the latest OpenWrt trunk, I found that config_get has stopped loading uncommitted uci changes from /tmp/.uci. I rely on this behavior, which had worked well for years. I found a change[1] in uci that’s responsible. The uci change makes uci_add_delta_path() reject any attempt to add ctx-savedir to the delta search path. However, in light of cli.c’s usage[2], there’s a problem: when processing a -P argument, it calls uci_add_delta_path() to add the original value of ctx-savedir to the delta search path before changing ctx-savedir. After this change, the uci command-line tool’s -P argument no longer acts as documented. Instead of adding a path to the delta search path, it just sets the default save directory. This behavior change appears to be unintentional, and as I mentioned, it’s broken a long-standing behavior that I rely on. This change became a part of OpenWrt at r45040[3] and is exposed to scripts that use /lib/functions.sh: that script sets LOAD_STATE=1, and its config_load calls /lib/config/uci.sh’s uci_load, which adds a -P argument to its “uci export” command when LOAD_STATE is nonempty. I’m happy to contribute a patch, but I’m not sure what [1] intended, so I’m e-mailing to raise awareness first. Mark [1] http://nbd.name/gitweb.cgi?p=uci.git;a=commitdiff;h=32815cf4959c [2] http://nbd.name/gitweb.cgi?p=uci.git;a=blob;f=cli.c;h=557472ecf421;hb=HEAD [3] https://dev.openwrt.org/changeset/45040/trunk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx: Add platform machine support for the Netgear WNDR3700v4
deca1064 rps...@arcor.de wrote: This patch adds platform machine support for the Netgear WNDR3700v4. Signed-off-by: Ralph Perlich rps...@arcor.de The WNDR3700v4 and WNDR4300 are almost identical, so much so that nearly everything you’ve added here duplicates the definitions that already exist for WNDR4300. I think it would be better to treat them as the same machine, in much the same way that the WNDR3700v1, WNDR3700v2, WNDR3800 and WNDRMACv2 share code. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] bug with recent busybox config changes
etienne.champet...@free.fr wrote: zabbix-agentd select BUSYBOX_CONFIG_UNAME and BUSYBOX_CONFIG_HOSTNAME, It's working ok in r39105 (419db8ef231eae6c0a514f32ff6c423c384900ca)(just before busybox config changes), but it's not in r39185 (13b222d757237eb7772eb7cf8433306ffd6b8ccd)(latest commit). does 'select' command need the symbol to be already in .config? because it was the case before but not now. Are you sure of r39125 busybox: add back support for top-level menuconfig based config overrides? The config symbol needs to show up somewhere. Here’s what I use in a local package called ifplugd_support to be able to have it select busybox ifplugd: In ifplugd_support/Makefile: define Package/ifplugd_support/config source $(SOURCE)/Config.in endef The contents of ifplugd_support/Config.in: -- config PACKAGE_ifplugd_support select BUSYBOX_CONFIG_IFPLUGD menu Busybox Configuration visible if false depends on PACKAGE_ifplugd_support if PACKAGE_busybox config BUSYBOX_CONFIG_IFPLUGD bool BUSYBOX_CONFIG_IFPLUGD endif endmenu -- I’m not thrilled about having to provide a Config.in for each of my local packages that depends on busybox features now, but this seems to be how things were intended to work under the new busybox configuration. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Has something changed the timing of network interface availability during startup?
I wrote: Are you suggesting that dnsmasq should be started out of a hotplug script? I suppose the answer is “yes:” I see r39152. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Has something changed the timing of network interface availability during startup?
It seems that at some point in the last three months (between r37989 and r39097), something about the way network interfaces are brought up changed. Interfaces that were formerly available at a certain point during startup are no longer necessarily available at that point. I first noticed this when I found that dnsmasq wasn’t responding to DNS queries. I have dnsmasq configured to bind to each desired interface’s address individually rather than to bind to to the wildcard address. This is accomplished by setting “option nonwildcard 1” in /etc/config/dhcp’s “config dnsmasq” section. With this setting in place, after boot, dnsmasq was not bound to port 53 on any address. I checked this with “netstat -an”. This is affecting some of my other startup scripts as well, which had been expecting the system to be in a certain state with respect to network interface availability based on their START= values. It seems that network devices are now brought up in the background, and may not even be available when any rc.d start script runs. Is this a new change with the ongoing netifd or procd work? In the new procd/netifd world, is there a better way to start services that depend on specific network interfaces? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] packages: nginx: fix libopenssl dependency
The build system doesn't understand this compound DEPENDS condition without it being wrapped in parentheses. menuconfig does understand it, so libopenssl would be selected if nginx needed it, but there was no guarantee that openssl would be built before nginx. Adding parentheses fixes the problem. This seems to be how compound conditions are generally handled in OpenWrt Makefiles. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: feeds/packages/net/nginx/Makefile === --- feeds/packages/net/nginx/Makefile (revision 36584) +++ feeds/packages/net/nginx/Makefile (working copy) @@ -57,7 +57,7 @@ SUBMENU:=Web Servers/Proxies TITLE:=Nginx web server URL:=http://nginx.org/ - DEPENDS:=+NGINX_PCRE:libpcre +NGINX_SSL||NGINX_HTTP_CACHE||NGINX_HTTP_AUTH_BASIC:libopenssl +NGINX_HTTP_GZIP:zlib +libpthread +NGINX_LUA:liblua + DEPENDS:=+NGINX_PCRE:libpcre +(NGINX_SSL||NGINX_HTTP_CACHE||NGINX_HTTP_AUTH_BASIC):libopenssl +NGINX_HTTP_GZIP:zlib +libpthread +NGINX_LUA:liblua MENU:=1 endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall3: source address used for NAT reflection
This works perfectly. Thanks, jow. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall3: source address used for NAT reflection
reflection_src_dip? That matches src_dip as used for SNAT rules, but makes it clear that it’s for reflection. (src_dip has a matching function instead of a rewriting function for DNAT rules.) I’ve got a strong preference to allow an interface name argument (“lan”) instead of requiring an IP address, which would make it another place to have to write the same LAN IP address configured elsewhere. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall3: source address used for NAT reflection
This would work just fine for me, although configuration’s meaning wouldn’t be nearly as evident without consulting some reference documentation. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx/ag71xx: Make the hardware link state drop when the interface is down
This is based on juhosg's patch to fully suspend an ag71xx device on phy_stop
and resume it on phy_start [1], along with my addition to set the initial state
to suspended, corresponding to the initial down state of the interface [2].
This makes the hardware link state on an ag71xx device track the up/down state
of its interface.
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016540.html
[2] https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016996.html
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index:
target/linux/ar71xx/patches-3.8/910-phy-add-phy_suspend-resume-helpers.patch
===
---
target/linux/ar71xx/patches-3.8/910-phy-add-phy_suspend-resume-helpers.patch
(revision 0)
+++
target/linux/ar71xx/patches-3.8/910-phy-add-phy_suspend-resume-helpers.patch
(working copy)
@@ -0,0 +1,21 @@
+--- a/include/linux/phy.h
b/include/linux/phy.h
+@@ -510,6 +510,18 @@ static inline int phy_read_status(struct
+ return phydev-drv-read_status(phydev);
+ }
+
++static inline void phy_suspend(struct phy_device *phydev)
++{
++ if (phydev-drv-suspend)
++ phydev-drv-suspend(phydev);
++}
++
++static inline void phy_resume(struct phy_device *phydev)
++{
++ if (phydev-drv-resume)
++ phydev-drv-resume(phydev);
++}
++
+ int genphy_restart_aneg(struct phy_device *phydev);
+ int genphy_config_aneg(struct phy_device *phydev);
+ int genphy_update_link(struct phy_device *phydev);
Index:
target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_phy.c
===
--- target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_phy.c
(revision 35844)
+++ target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_phy.c
(working copy)
@@ -47,6 +47,7 @@
struct ag71xx_platform_data *pdata = ag71xx_get_pdata(ag);
if (ag-phy_dev) {
+ phy_resume(ag-phy_dev);
phy_start(ag-phy_dev);
} else if (pdata-mii_bus_dev pdata-switch_data) {
ag71xx_ar7240_start(ag);
@@ -61,10 +62,12 @@
struct ag71xx_platform_data *pdata = ag71xx_get_pdata(ag);
unsigned long flags;
- if (ag-phy_dev)
+ if (ag-phy_dev) {
phy_stop(ag-phy_dev);
- else if (pdata-mii_bus_dev pdata-switch_data)
+ } else if (pdata-mii_bus_dev pdata-switch_data) {
+ phy_suspend(ag-phy_dev);
ag71xx_ar7240_stop(ag);
+ }
spin_lock_irqsave(ag-lock, flags);
if (ag-link) {
@@ -218,10 +221,16 @@
if (pdata-switch_data)
return ag71xx_ar7240_init(ag);
+ int ret;
if (pdata-phy_mask)
- return ag71xx_phy_connect_multi(ag);
+ ret = ag71xx_phy_connect_multi(ag);
+ else
+ ret = ag71xx_phy_connect_fixed(ag);
- return ag71xx_phy_connect_fixed(ag);
+ if (ag-phy_dev)
+ phy_suspend(ag-phy_dev);
+
+ return ret;
}
void ag71xx_phy_disconnect(struct ag71xx *ag)
@@ -230,6 +239,8 @@
if (pdata-switch_data)
ag71xx_ar7240_cleanup(ag);
- else if (ag-phy_dev)
+ else if (ag-phy_dev) {
phy_disconnect(ag-phy_dev);
+ phy_suspend(ag-phy_dev);
+ }
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] firewall3: source address used for NAT reflection
Has the source address used for NAT reflection changed with firewall3? At r35938, I’m seeing that when I attempt to connect from a host on my LAN to a redirected port on my main router’s WAN address, the router reflects the request back in to my LAN using its own WAN address as the source address. I noticed this because some of my internal hosts don’t have a route to this WAN address and can’t respond to requests reflected in this way. Previously, I was running r35844, which didn’t have this problem. It used the router’s LAN address as the source address for these reflected packets. Looking through “iptables -t nat -L” confirms that there’s been a change. Previously I’d see in nat_reflection_out SNAT tcp -- 192.168.1.0/24 192.168.1.2 tcp dpt:443 /* wan */ to:192.168.69.1 and now I see in zone_lan_postrouting (w.x.y.z is my WAN IP address) SNAT tcp -- 192.168.1.0/24 192.168.1.2 tcp dpt:443 to:w.x.y.z Is it possible to configure the source address used for these reflected packets? I’d prefer to use the LAN address for this because all of my hosts have a route to it by virtue of being connected to this network, and because the LAN address is much less likely to change than the WAN address. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Firewall/NAT reflection now requires |option dest lan|
Since the recent enhancements to NAT reflection were made, I found that reflection stopped working on my networks. I was unable to connect from hosts on a LAN to its router’s WAN-side address and have the port mappings from “config redirect” sections be effective. Instead, I got “connection refused.” Connecting from outside of a network, the redirects worked properly. Adding “option dest lan” to each of my “config redirect” sections resolved this problem. Previously, “option dest” was optional for DNAT. It seems that it’s still optional, except that reflection doesn’t work if it’s missing. If it’s going to be required now, then perhaps the firewall scripts should warn if it’s missing. If it shouldn’t be required, then count this message as a bug report. To me, it seems silly to have to specify the destination zone name when it’s implied by dest_ip. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Upgrade nginx to 1.2.3
Florian Fainelli wrote: On Tuesday 21 August 2012 12:32:17 Mark Mentovai wrote: Changelog: http://nginx.org/en/CHANGES-1.2 Signed-off-by: Mark Mentovai m...@moxienet.com Applied in r34495, thanks Mark! Thanks, Florian. They’re up to 1.2.5 now, so I’ve moved on to using this. Signed-off-by: Mark Mentovai m...@moxienet.com Index: packages/net/nginx/Makefile === --- packages/net/nginx/Makefile (revision 34495) +++ packages/net/nginx/Makefile (working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=nginx -PKG_VERSION:=1.2.3 +PKG_VERSION:=1.2.5 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://nginx.org/download/ -PKG_MD5SUM:=0a986e60826d9e3b453dbefc36bf8f6c +PKG_MD5SUM:=4f5a55187a3d45fa37d99d07ddd90800 PKG_BUILD_PARALLEL:=1 PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ag71xx: making the link state drop
Weedy weedy2...@gmail.com wrote: On 27/08/12 07:34 AM, Gabor Juhos wrote: The problem is that PHYLIB in Linux does not fully stops the PHY device when a driver issues a phy_stop call. Copy the attached patches into 'target/linux/ar71xx/patches-3.3', then do a 'make target/linux/clean world'. With these patches, the PHY of the WAN port will be powered down after 'ifconfig eth1 down' (on the WNDR3700 at least). Regards, Gabor Why didn't this get committed? In case it does… I also added this patch to ensure that the initial link state is down. Without this patch, the link state would be up even though the interface was down on boot. With this patch, the link state stays down until the interface is brought up. I’m using this patch in conjunction with Gabor’s original pair of patches on all of my WNDR3700 (v1), WNDR3700v2, WNDR3800, and WNDRMACv2 units. It’s been working very well. Mark ag71xx_suspend_more.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Understanding LEDs on WNDR3800
Adam Gensler wrote:
Thanks for the reply, I appreciate the clarification.
May I ask how you're turning the WAN LED to green in your setup? What
mechanism do you use to do it? I've been unsuccesful thus far but perhaps I'm
not trying the proper set of adjustments. More specifically can you share your
/etc/config/network and also /etc/config/system?
I'm attaching three of my local patches that deal with the WAN LED:
netifd_dhcpc_hotplug.patch adds a hotplug action for any DHCP event. Upon
any DHCP event, scripts in /etc/hotplug.d/dhcpc will run with the action
environment variable set to bound, renew, leasefail, nak, or
deconfig.
ifplugd_support.patch adds a new package, ifplugd_support, that sets up
ifplugd to watch the interface backing WAN, and ties it into a hotplug
action. Upon any ifplugd event, scripts in /etc/hotplug.d/ifplugd will run
with the IFPLUGD_INTERFACE environment variable set to the interface name
and the IFPLUGD_ACTION environment variable set to the argument to the
ifplugd.action script. I've seen this argument not be correct, so I
recommend using the IFPLUGD_CURRENT environment variable set by ifplugd in
preference to IFPLUGD_ACTION. Possible values are down, up, and
error. This patch also includes a hotplug action to request DHCP lease
renewal on the WAN port when the cable is (re)connected. In order to use
this patch, you need to enable ifplugd in busybox
(CONFIG_BUSYBOX_CONFIG_IFPLUGD=y, Base system/busybox/Networking
Utilities/ifplugd) and also enable this package
(CONFIG_PACKAGE_ifplugd_support=y, Custom/ifplugd_support).
wndr3700_wan_led.patch contains hotplug actions for both ifplugd and
udhcpc. They both operate on the WAN interface only. The ifplugd action
will set the WAN LED to amber when the cable is disconnected. When the
cable is connected and the WAN interface is not being configured by DHCP,
the WAN LED is set to green if the link speed is gigabit (or faster?) or
amber if it's slower. The dhcpc action sets the WAN LED to green when a
DHCP lease is obtained or renewed, and amber for other DHCP events. This
patch also removes configuration of the WAN LED from /etc/config/system,
otherwise, /etc/rc.d/S96led would turn the LED amber, possibly after the
ifplugd or dhcpc actions set it properly. However, if you're sysupgrading
and preserving your existing configuration files, you'll need to remove
the config led led_wan section from /etc/config/system by hand, because
the uci-defaults script only sets the defaults, it doesn't modify existing
configurations.
It would probably be slicker if the link speed control could be handled
in-kernel by an LED trigger that tracks link speed. netifd polls the link
state and it isn't perfect, although it gets pretty close. I set it up
this way because I already had netifd set up to watch the WAN port to
trigger DHCP renewal. I probably wouldn't have gone to the trouble at all
just for LEDs otherwise. Similarly, I set up the dhcpc hotplug support for
another reason, and tying in the LED was simple at that point.
As mentioned, my /etc/config/system doesn't have a config led led_wan
section. The LED configuration in /etc/config/network is at the defaults:
port 1 = 6, port 2 = 9, and port 5 = 2.Index: package/netifd/files/lib/netifd/dhcp.script
===
--- package/netifd/files/lib/netifd/dhcp.script (revision 33310)
+++ package/netifd/files/lib/netifd/dhcp.script (working copy)
@@ -47,13 +47,17 @@
proto_send_update $INTERFACE
}
-case $1 in
- deconfig)
- deconfig_interface
- ;;
- renew|bound)
- setup_interface
- ;;
-esac
+(
+ case $1 in
+ deconfig)
+ deconfig_interface
+ ;;
+ renew|bound)
+ setup_interface
+ ;;
+ esac
+)
+env action=${1} hotplug-call dhcpc
+
exit 0
Index: package/ifplugd_support/Makefile
===
--- package/ifplugd_support/Makefile(revision 0)
+++ package/ifplugd_support/Makefile(revision 0)
@@ -0,0 +1,54 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ifplugd_support
+PKG_VERSION:=0.1
+PKG_RELEASE:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/ifplugd_support
+ SECTION:=base
+ CATEGORY:=Custom
+ TITLE:=ifplugd support
+ MAINTAINER:=Mark Mentovai m...@moxienet.com
+ DEPENDS:=@BUSYBOX_CONFIG_IFPLUGD
+endef
+
+define Package/ifplugd_support/description
+ ifplugd support
+ Enables ifplugd to monitor the WAN interface, requesting DHCP lease renewal
+ upon cable reconnection, and allowing further extension via hotplug.
+endef
+
+define Build/Configure
+endef
+
+define Build/Compile
+endef
+
+define Package/ifplugd_support/install
+ $(INSTALL_DIR) $(1)/etc/init.d
+ $(INSTALL_BIN) files/ifplugd $(1)/etc/init.d
+ $(INSTALL_DIR) $(1)/etc/ifplugd
Re: [OpenWrt-Devel] Understanding LEDs on WNDR3800
Adam Gensler wrote: I recently acquired a Netgear WNDR3800. To date I've been playing exclusively on an alix 2D13 platform so I have a few new things to learn. In any case, I've been tinkering with the LEDs and I'm having some trouble getting my head around a few things. Specifically: 1. How does one accurately control the WAN LED? /etc/config/network has this: […] Supposedly this controls the orange WAN LED. However, setting option led 0 does not turn the LED off as indicated. It stops blinking but it doesn't turn off. How do I turn off the orange LED? I don’t know if you can, then. 2. Why is the orange component of the WAN LED configured/controlled via /etc/config/network yet the wan:green LED is controlled via /etc/config/system? Is there some reason I'm not immediately understanding? Is it because the orange LED for WAN isn't listed under /sys/class/leds? This would lead me to believe that this is controlled via some different mechanism than the green LED on the hardware. The original firmware for this router doesn’t use green/amber on the WAN LED to indicate the same thing that it uses green/amber for on the LAN switch port LEDs. For the LAN switch ports, the LED colors indicate link speed. This is easily handled in hardware. For the WAN port, the LED color indicates whether an Internet connection has been established. I don’t recall whether the original firmware was probing some site or whether it was just deciding it had connectivity when it obtained a DHCP lease, but regardless of the mechanism it was using to make this determination, it’s something that’s best handled in software. Accordingly, for the WAN LED, the hardware was left to handle what it does best (turning the LED on for link presence, and blinking it for activity), and software handled the color. (In my own builds, I mimic something close to the original firmware’s meaning for the WAN LED by turning the LED green when a DHCP lease is obtained or renewed, and amber when lost, via a hotplug action launched from /lib/netifd/dhcp.script. For cases where WAN isn’t configured by DHCP, I set the LED color based on the link speed when a link is detected by ifplugd.) 3. Along with #2, why is the green LED pre-configured in /etc/config/system by /etc/uci-defaults/leds on first boot? The preconfiguration doesn't actually do anything. What is this for? Am I missing something? You’re correct, I don’t believe it actually does anything (and I’ve removed it from my own builds). All it’s doing is setting the WAN LED to “not green” (thus amber), but I think that’s the default. Having this in /etc/config/system does provide a template for you to modify if you want to change the behavior of the LED, although given the hardware-software-hybrid nature of that LED, it’s less useful than for LEDs strictly under software control. 4. The wifi adapters, ath9k-phy0 and ath9k-phy1 apparently default to the respective phy[0|1]tpt trigger. This also isn't in /etc/config/system. It seems to happen elsewhere, but I haven't found the place that controls this. How is this accomplished? Is this some ath9k driver default? It is. This happens in compat-wireless/drivers/net/wireless/ath/ath9k/init.c. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ag71xx: making the link state drop
Gabor Juhos wrote: The problem is that PHYLIB in Linux does not fully stops the PHY device when a driver issues a phy_stop call. Copy the attached patches into 'target/linux/ar71xx/patches-3.3', then do a 'make target/linux/clean world'. With these patches, the PHY of the WAN port will be powered down after 'ifconfig eth1 down' (on the WNDR3700 at least). This works perfectly. Thanks so much, Gabor! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ag71xx: making the link state drop
Is there a way to make the link state drop on an ag71xx interface, so that it appears to whatever equipment is connected to the port that the cable has been disconnected? I've got a WNDR3700-family device and I need to make it appear to the equipment connected to its eth1 interface that the cable has been disconnected. ifconfig eth1 down doesn't alter the link state at all. It'd be OK if the state just dropped momentarily and then returned. So far, the best I've been able to do is reboot the entire WNDR3700. That's a more drastic approach than I'd like to use, as there are other things happening on the system that I'd rather not interrupt. I'm very open to the possibility of ag71xx driver changes to make this work (either as a local change or something for wider distribution) but I haven't found any data sheets for this device, so I'd basically be starting by stabbing around in the dark. Does anyone have any pointers? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] Keep /etc/nginx/ on sysupgrade
John Crispin wrote: not merging any new stuff and/or updates atm ... -- https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016411.html is there a specific reason, such as a security fix or is it just a feature update ? No security fixes here, just bug fixes. It's OK to hold off. I missed the stabilization announcement. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Keep /etc/nginx on sysupgrade
Jo-Philipp Wich wrote: It looks like conffiles can only save files, not entire directories. /etc/nginx is a directory. Should conffiles be fixed to work with directories too? It works fine with directories, see include/package-ipkg.mk, the code below ifneq ($$(KEEP_$(1)),) I see. The existing feeds/packages/net/nginx/Makefile already lists the files under /etc/nginx that ship in the package in its conffiles definition, but this doesn't result in a keep file in the package because include/package-ipkg.mk will only add entries to a keep file when they aren't present as files in the package. Is this intentional? The net effect is that changes to conffiles aren't preserved across sysupgrade when default conffiles are present in a package. If that's the case, what's the point of even listing these files in conffiles? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Keep /etc/nginx on sysupgrade
Jo-Philipp Wich wrote: But they will get recorded by opkg, which is another source sysupgrade uses to assemble the list of files to get backed up. This is the part I was missing. Thanks for the explanation. I've submitted a v2 patch in case it's thought to be generally useful, otherwise I'll just carry it locally. I also submitted a patch to upgrade nginx 1.2.3 separately a few days ago. That shouldn't be controversial at all. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] Keep /etc/nginx/ on sysupgrade
This allows additional files in /etc/nginx/, such as SSL certificates, tobe saved on sysupgrade. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: packages/net/nginx/Makefile === --- packages/net/nginx/Makefile (revision 33213) +++ packages/net/nginx/Makefile (working copy) @@ -48,12 +48,7 @@ config_files=nginx.conf mime.types fastcgi_params koi-utf koi-win win-utf define Package/nginx/conffiles -/etc/nginx/nginx.conf -/etc/nginx/mime.types -/etc/nginx/fastcgi_params -/etc/nginx/koi-utf -/etc/nginx/koi-win -/etc/nginx/win-utf +/etc/nginx/ endef ADDITIONAL_MODULES:= ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] Keep /etc/nginx/ on sysupgrade
John Crispin wrote: On 24/08/12 15:14, Mark Mentovai wrote: This allows additional files in /etc/nginx/, such as SSL certificates, tobe saved on sysupgrade. Signed-off-by: Mark Mentovai m...@moxienet.com after not reading the 100 mails leading up to this patch i expected something big ;) Yeah, I had misunderstood a couple of things, it's way easier than I was making it. Thanks, applied in r33271 Thanks, John. Can you take the nginx 1.2.3 upgrade I sent in a few days ago too? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Keep /etc/nginx on sysupgrade
Jo-Philipp Wich wrote: Hi. You do not need to ship a keep file, it is enough to add /etc/nginx to the conffiles define. It looks like conffiles can only save files, not entire directories. /etc/nginx is a directory. Should conffiles be fixed to work with directories too? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Upgrade nginx to 1.2.3
Changelog: http://nginx.org/en/CHANGES-1.2 Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: packages/net/nginx/Makefile === --- packages/net/nginx/Makefile (revision 33213) +++ packages/net/nginx/Makefile (working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=nginx -PKG_VERSION:=1.2.2 +PKG_VERSION:=1.2.3 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://nginx.org/download/ -PKG_MD5SUM:=53105bbe3ac9319db54d9eb46119695b +PKG_MD5SUM:=0a986e60826d9e3b453dbefc36bf8f6c PKG_BUILD_PARALLEL:=1 PKG_INSTALL:=1 Index: packages/net/nginx/patches/101-feature_test_fix.patch === --- packages/net/nginx/patches/101-feature_test_fix.patch (revision 33213) +++ packages/net/nginx/patches/101-feature_test_fix.patch (working copy) @@ -11,7 +11,7 @@ ngx_feature_libs= --- a/auto/cc/conf +++ b/auto/cc/conf -@@ -149,7 +149,7 @@ if [ $NGX_PLATFORM != win32 ]; then +@@ -155,7 +155,7 @@ if [ $NGX_PLATFORM != win32 ]; then else ngx_feature=C99 variadic macros ngx_feature_name=NGX_HAVE_C99_VARIADIC_MACROS @@ -20,7 +20,7 @@ ngx_feature_incs=#include stdio.h #define var(dummy, ...) sprintf(__VA_ARGS__) ngx_feature_path= -@@ -163,7 +163,7 @@ if [ $NGX_PLATFORM != win32 ]; then +@@ -169,7 +169,7 @@ if [ $NGX_PLATFORM != win32 ]; then ngx_feature=gcc variadic macros ngx_feature_name=NGX_HAVE_GCC_VARIADIC_MACROS ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Keep /etc/nginx on sysupgrade
Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: packages/net/nginx/Makefile === --- packages/net/nginx/Makefile (revision 33213) +++ packages/net/nginx/Makefile (working copy) @@ -103,6 +103,8 @@ $(INSTALL_DATA) $(addprefix $(PKG_INSTALL_DIR)/etc/nginx/,$(config_files)) $(1)/etc/nginx/ $(INSTALL_DIR) $(1)/etc/init.d $(INSTALL_BIN) ./files/nginx.init $(1)/etc/init.d/nginx + $(INSTALL_DIR) $(1)/lib/upgrade/keep.d + $(INSTALL_DATA) ./files/nginx.keep $(1)/lib/upgrade/keep.d/nginx endef $(eval $(call BuildPackage,nginx)) Index: packages/net/nginx/files/nginx.keep === --- packages/net/nginx/files/nginx.keep (revision 0) +++ packages/net/nginx/files/nginx.keep (revision 0) @@ -0,0 +1 @@ +/etc/nginx/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Bridged interface MAC address changes during DHCP client transaction wtih netifd
Felix Fietkau wrote: I did add code to netifd to take care of this a while ago, but there was a bug that prevented it from working. This bug is fixed in the latest version, committed in r32506 Great, I confirmed that this is working as it used to now. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Bridged interface MAC address changes during DHCP client transaction wtih netifd
I suspect that the netifd changes are related, since that looks like the only relevant area of major activity in the past month when this began happening. Then again, the timing-sensitive nature means that the underlying problem may have been present for a while, and only exposed with the recent netifd changes. I've noticed that it's possible for the MAC address to change during a DHCP client transaction when OpenWrt is configured to obtain a DHCP lease on a bridged interface. In my example, I have a WNDR3700 configured as follows in /etc/config/network: config interface lan option ifname eth0.1 option type bridge option protodhcp wlan0 and wlan1 are also configured to join this bridged interface, both configured in /etc/config/wireless with: config wifi-iface option network lan eth0.1's MAC address is c6:xx:xx:xx:xx:01 (with the locally-administered [LA] bit set). wlan0's is c4:xx:xx:xx:xx:01, and wlan1's is c4:xx:xx:xx:xx:03. On the DHCP server (also OpenWrt running dnsmasq), I observe the DHCP transaction when the WNDR3700 boots: Jun 26 12:21:57 gw1 daemon.info dnsmasq-dhcp[2285]: DHCPDISCOVER(br-lan) c6:xx:xx:xx:xx:01 Jun 26 12:21:57 gw1 daemon.info dnsmasq-dhcp[2285]: DHCPOFFER(br-lan) 192.168.1.211 c6:xx:xx:xx:xx:01 Jun 26 12:21:57 gw1 daemon.info dnsmasq-dhcp[2285]: DHCPREQUEST(br-lan) 192.168.1.211 c4:xx:xx:xx:xx:01 Jun 26 12:21:57 gw1 daemon.info dnsmasq-dhcp[2285]: DHCPACK(br-lan) 192.168.1.211 c4:xx:xx:xx:xx:01 Note that the MAC address changes from having the LA bit set (c6:xx:xx:xx:xx:01) when the client sends its DHCPDISCOVER to not having the LA bit set (c6:xx:xx:xx:xx:01) when it sends its DHCPREQUEST. This is because the br-lan interface begins life taking the MAC address of its only initial underlying interface, eth0.1, which has the LA bit set. When wlan0 is added to this bridge, the bridge winds up taking that interface's MAC address (c4:xx:xx:xx:xx:01) instead. I have observed that this occurs repeatably immediately in the middle of the DHCP transaction intended to assign the interface's address. The logs from the client side confirm this: Dec 31 19:00:12 ap2 kern.debug kernel: [ 12.89] ar71xx: pll_reg 0xb8050010: 0x Dec 31 19:00:12 ap2 kern.info kernel: [ 12.89] eth0: link up (1000Mbps/Full duplex) Dec 31 19:00:12 ap2 kern.info kernel: [ 12.89] device eth0.1 entered promiscuous mode Dec 31 19:00:12 ap2 kern.info kernel: [ 12.90] device eth0 entered promiscuous mode Dec 31 19:00:12 ap2 kern.info kernel: [ 12.92] br-lan: port 1(eth0.1) entered forwarding state Dec 31 19:00:12 ap2 kern.info kernel: [ 12.92] br-lan: port 1(eth0.1) entered forwarding state Dec 31 19:00:13 ap2 daemon.notice netifd: lan (628): udhcpc (v1.19.4) started Dec 31 19:00:13 ap2 daemon.notice netifd: lan (628): Sending discover... Dec 31 19:00:14 ap2 kern.info kernel: [ 14.70] device wlan0 entered promiscuous mode Dec 31 19:00:14 ap2 kern.info kernel: [ 14.92] br-lan: port 1(eth0.1) entered forwarding state Dec 31 19:00:14 ap2 kern.info kernel: [ 14.96] br-lan: port 2(wlan0) entered forwarding state Dec 31 19:00:14 ap2 kern.info kernel: [ 14.96] br-lan: port 2(wlan0) entered forwarding state Dec 31 19:00:15 ap2 daemon.notice netifd: lan (628): Sending select for 192.168.1.211... Dec 31 19:00:15 ap2 daemon.notice netifd: lan (628): Lease of 192.168.1.211 obtained, lease time 43200 Dec 31 19:00:15 ap2 daemon.notice netifd: Interface 'lan' is now up Jun 26 12:21:58 ap2 kern.info kernel: [ 16.96] br-lan: port 2(wlan0) entered forwarding state Jun 26 12:21:58 ap2 kern.info kernel: [ 17.48] device wlan1 entered promiscuous mode Jun 26 12:22:01 ap2 kern.info kernel: [ 20.25] br-lan: port 3(wlan1) entered forwarding state Jun 26 12:22:01 ap2 kern.info kernel: [ 20.26] br-lan: port 3(wlan1) entered forwarding state Jun 26 12:22:03 ap2 kern.info kernel: [ 22.26] br-lan: port 3(wlan1) entered forwarding state Using a variable hardware address for a DHCP transaction is no good. Having the hardware address be unpredicatable is also a problem. I discovered this problem when debugging why a static DHCP address assignment (config host in /etc/config/dhcp on the server) was not effective. If I use c6:xx:xx:xx:xx:01 on the server, then the client won't be able to DHCPREQUST the desired address once it begins using MAC address c4:xx:xx:xx:xx:01. If I use c4:xx:xx:xx:xx:01 on the server, then the server won't send a DHCPOFFER for the desired address because the DHCPREQUEST will have a different MAC address. Ultimately, it may just be a bad idea to have a bridge's MAC address change once established, at least as long as the bridge still contains an underlying interface that owns the MAC address it's using. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] Bridged interface MAC address changes during DHCP client transaction wtih netifd
Philip Prindeville wrote: On 6/26/12 11:02 AM, Jo-Philipp Wich wrote: That is nothing netifd or OpenWrt does, it is the behaviour of Linux bridges - they'll assume the lowest MAC address of all their member ifaces. Imo that should be changed in the Kernel, it shoud fix the bridge MAC to the one of the first member iface added, and then never change it again even if the ports change. I thought that used to be its behavior. Did that change? I remember having similar issues both with wireless LANs bridged to ethernet, as well as Ethernet bridged to DSL with PPPoE... The old behavior was that the first interface to join the bridge would set the bridge's address. It looks like this used to be handled by the pre-netifd /lib/network/config.sh: https://dev.openwrt.org/browser/trunk/package/base-files-network/files/lib/network/config.sh?rev=31979#L204 See line 232, where the bridge interface, when initially created, would be given the MAC address of its first member interface. That change was introduced in r26990: https://dev.openwrt.org/changeset/26990 That would render the new (Linux kernel default) behavior of always making a bridge interface use the lowest MAC address of any member interface a regression introduced with the netifd change. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] include/image.mk: /tmp should have mode 1777
It looks like a similar change was made at r32073, adding chmod 1777 $(1)/tmp to package/base-files/Makefile. That has the effect of setting the sticky bit on /tmp in base-files.ipk, but the sticky bit is still clear in the root filesystem of generated images. Either this patch is needed, or both the $(INSTALL_DIR) and chmod of /tmp need to be removed from include/image.mk. The latter approach relies on /tmp being provided by base-files (or any other package baked into the image) and having the correct mode, which as of r32073, it does. As it stands now, $(INSTALL_DIR) resets the mode to 0755, and the chmod that follows reset it to 0777, neither of which respect the desired 1777 mode now used in base-files.ipk. I wrote: On the off chance that the root filesystem's /tmp is used directly as a temporary directory instead of having a tmpfs mounted over it, it should have the sticky bit set. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: include/image.mk === --- include/image.mk (revision 31782) +++ include/image.mk (working copy) @@ -146,7 +146,7 @@ - $(FIND) $(TARGET_DIR) -type f -perm +0100 -print0 | $(XARGS) -0 chmod u+rwx,g+rx,o+rx - $(FIND) $(TARGET_DIR) -type d -print0 | $(XARGS) -0 chmod u+rwx,g+rx,o+rx $(INSTALL_DIR) $(TARGET_DIR)/tmp - chmod 0777 $(TARGET_DIR)/tmp + chmod 1777 $(TARGET_DIR)/tmp endef define Image/mkfs/prepare ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: correctly detect NETGEAR WNDRMAC
Are you sure this is universally correct for all WNDRMAC units? It's possible that the N there is actually variable, and part of something else that shows up at that location in flash. `hexdump -C /dev/mtd5` (assuming mtd5 is art in /proc/mtd) should help identify what that N is actually doing, which in turn might indicate whether it's useful for identifying the model or not. Роман А. aka BasicXP wrote: This patch helps properly detect a WNDRMAC device. Before this patch the model is detected as NETGEAR ?N. Signed-off-by: Roman A. aka BasicXP x12ozmo...@ya.ru --- Index: target/linux/ar71xx/base-files/lib/ar71xx.sh === --- target/linux/ar71xx/base-files/lib/ar71xx.sh (revision 32267) +++ target/linux/ar71xx/base-files/lib/ar71xx.sh (working copy) @@ -41,6 +41,8 @@ model=$(ar71xx_get_mtd_offset_size_format art 56 10 %c) if [ -z $model ] || [ $model = $'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ]; then machine=NETGEAR WNDR3700v2 + elif [ -z $model ] || [ $model = $'\xff\xff\xff\xff\xff\xff\xff\xff\xffN' ]; then + machine=NETGEAR WNDRMAC else machine=NETGEAR $model fi___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: correctly detect NETGEAR WNDRMAC
That’s probably good enough to detect WNDRMAC (v1), then. Interesting that NETGEAR put the default SSID at offset 0x41 on the original WNDRMAC, and offset 0x42 on later models. In case you’re curious, here’s the top of the art block from a WNDRMACv2: M0 M0 M0 M0 M0 M0 M1 M1 M1 M1 M1 M1 M2 M2 M2 M2 || 0010 M2 M2 SS SS SS SS SS SS SS SS SS SS SS SS SS SS |MMSS| 0020 SS SS SS SS SS SS SS 00 01 32 39 37 36 33 36 35 |SSS..2976365| 0030 34 2b 31 36 2b 31 32 38 57 4e 44 52 4d 41 43 76 |4+16+128WNDRMACv| 0040 32 00 4e 45 54 47 45 41 52 nn nn 00 00 00 00 00 |2.NETGEARnn.| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0060 00 00 PP PP PP PP PP PP PP PP PP PP PP PP PP PP |..PP| 0070 PP PP 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |PP..| 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || WNDR3800 is similar. I guess that adding an extra character to the hd_id when it went from +16+64 to +16+128 in conjunction with wanting to keep ten characters for the model name (WNDR3x00vN?) required things to get bumped over by a byte. Roman A. aka BasicXP wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have done this already, it's part of the preconfigured Wi-Fi information that is printed on the bottom of the the router. The SSID is always NETGEARXX, where XX is a random number. The N letter is the first letter of the SSID. Here is the part of hexdump output of my WNDRMAC (S letters hide the serial number, P - the preconfigured Wi-Fi password, M - router's MAC addresses): MM MM MM MM MM MM MM MM MM MM MM MM MM MM MM MM || 0010 MM MM SS SS SS SS SS SS SS SS SS SS SS SS SS SS |..SS| 0020 SS SS SS SS SS SS SS 00 05 ff ff ff ff ff ff ff |SSS.| 0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || 0040 ff 4e 45 54 47 45 41 52 34 33 00 ff ff ff ff ff |.NETGEAR43..| 0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || 0060 ff PP PP PP PP PP PP PP PP PP PP PP PP PP PP PP |.PPP| 0070 PP 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff |P...| 0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || My guess is that this should work on all WNDRMACs, although I only have one device to test this. 15.06.2012 20:19, Mark Mentovai пишет: Are you sure this is universally correct for all WNDRMAC units? It's possible that the N there is actually variable, and part of something else that shows up at that location in flash. `hexdump -C /dev/mtd5` (assuming mtd5 is art in /proc/mtd) should help identify what that N is actually doing, which in turn might indicate whether it's useful for identifying the model or not. Роман А. aka BasicXP wrote: This patch helps properly detect a WNDRMAC device. Before this patch the model is detected as NETGEAR ?N. Signed-off-by: Roman A. aka BasicXP x12ozmo...@ya.ru --- Index: target/linux/ar71xx/base-files/lib/ar71xx.sh === --- target/linux/ar71xx/base-files/lib/ar71xx.sh (revision 32267) +++ target/linux/ar71xx/base-files/lib/ar71xx.sh (working copy) @@ -41,6 +41,8 @@ model=$(ar71xx_get_mtd_offset_size_format art 56 10 %c) if [ -z $model ] || [ $model = $'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ]; then machine=NETGEAR WNDR3700v2 + elif [ -z $model ] || [ $model = $'\xff\xff\xff\xff\xff\xff\xff\xff\xffN' ]; then + machine=NETGEAR WNDRMAC else machine=NETGEAR $model fi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) iQIcBAEBCgAGBQJP22f/AAoJEEyDwVxhh5pHMFYQAIIsUqwpaffW/cjcsd/UiynF O4vBz8ocMzCR0lizVPAtQ1ZzWuD7Z3FmAqz5acZQSS+336bXuKG0CLTmrXRBKEoO /UnUsYxncGbyOJ/bWZ9s0VwL2oELBXrR+mJ61QJrJWsUzLMOUfF2EVg+lgCCUAzq rgcTcCnMcoJQzxGFbisi4GzlGqLucESLmBoulLCd/IkJheVrLprQTg4CIrIoPPno Jm+xUMX6qEDx+YaMwvtSXeQN4Zde4thLG1aeMBw+51Y5eeCsZ7KZsET9Q9sviilz kBBIcVzVLoSulNI/tls0atFkXY6Hu7z8xhXmnfqdzM+r5dxnF+NRjNy+Pt9wTHGN w4Si2N0YVZkBECvJXRPNzkMTeebhGRq3nLkYT3GA/ActPFylOBkPPMEnrl+xoR6t FnnOQulAUQBUuXI4XFone6t8mOOo7lgKgCBuiDVJV3wvt0PkzmdnUbZVu5vnQPnS ATzb6PKsLNM+0NCfUugABU0DXUBCBCZ8xrB8Um96GeVkAq8DQu1ofPScHu3OlKov APuRQTFYJ0WRG71i87QtJOjw3hPjX4mPlS1gN5cVOfFrp5mKJgStRT9/E+P/JwD3 Q7LMPqOkaj72vWskn967XheiYHSCtZZT9rqRwcGjeAjKe94TgX5A/IgawNKTnoGi 5wayIe8rFRaDKmSK2gk3 =NLyH -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] package/dnsmasq: permit UCI configuration of --dhcp-fqdn option
This adds a new boolean option, fqdn, to the config dnsmasq section of /etc/config/dhcp. The default is off. When set on, it enables the dhcp-fqdn option to dnsmasq. dhcp-fqdn causes dnsmasq's DNS server to not resolve unqualifed local hostnames. The domain option is required when using fqdn. Local hostnames will remain available for lookup using fully-qualified names. Signed-off-by: Mark Mentovai m...@moxienet.com Index: package/dnsmasq/files/dnsmasq.init === --- package/dnsmasq/files/dnsmasq.init (revision 31782) +++ package/dnsmasq/files/dnsmasq.init (working copy) @@ -88,6 +88,7 @@ append_bool $cfg expandhosts --expand-hosts append_bool $cfg enable_tftp --enable-tftp append_bool $cfg nonwildcard --bind-interfaces + append_bool $cfg fqdn --dhcp-fqdn append_parm $cfg dhcpscript --dhcp-script append_parm $cfg cachesize --cache-size ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4] package/dnsmasq: allow inhibition of search line in resolv.conf
When dnsmasq is configured with a domain option in the config dnsmasq
section of /etc/config/dhcp, it causes a search line to be added to
/etc/resolv.conf naming the domain specified. For situations where this is
undesirable, this can now be bypassed with the search_domain boolean option.
The default, on, produces the current behavior. Setting it to off avoids
adding a search line to resolv.conf. option domain still retains its other
functions such as providing the value for the --domain option to dnsmasq.
Signed-off-by: Mark Mentovai m...@moxienet.com
Index: package/dnsmasq/files/dnsmasq.init
===
--- package/dnsmasq/files/dnsmasq.init (revision 31782)
+++ package/dnsmasq/files/dnsmasq.init (working copy)
@@ -7,6 +7,7 @@
DNS_SERVERS=
DOMAIN=
+SEARCH_DOMAIN=1
INSERT_LANADDR=1
CONFIGFILE=/var/etc/dnsmasq.conf
@@ -110,6 +111,7 @@
append_parm $cfg dhcp_boot --dhcp-boot
config_get DOMAIN $cfg domain
+ config_get_bool SEARCH_DOMAIN $cfg search_domain 1
config_get_bool INSERT_LANADDR $cfg insert_lanaddr 1
config_get_bool readethers $cfg readethers
@@ -460,7 +462,8 @@
service_start /usr/sbin/dnsmasq -C $CONFIGFILE {
rm -f /tmp/resolv.conf
- [ -n $DOMAIN ] echo search $DOMAIN /tmp/resolv.conf
+ [ $SEARCH_DOMAIN -ne 0 ] [ -n $DOMAIN ]
+ echo search $DOMAIN /tmp/resolv.conf
DNS_SERVERS=$DNS_SERVERS 127.0.0.1
for DNS_SERVER in $DNS_SERVERS ; do
echo nameserver $DNS_SERVER /tmp/resolv.conf
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] package/dnsmasq: remove obsolete /etc/dnsmasq.conf
Since r31182, dnsmasq is configured by a configuration file at /var/etc/dnsmasq.conf generated by dnsmasq's start script from its UCI configuration. It is no longer configured by command-line arguments. dnsmasq is started by telling it (via the -C option) to use /var/etc/dnsmasq.conf as its configuration file. As such, it never consults /etc/dnsmasq.conf. /etc/dnsmasq.conf was added in r17663 when dnsmasq was still configured by command-line arguments as an example file and location to place options too cumbersome to put on the command line. Because this file will no longer be consulted, it is obsolete and should be removed from the dnsmasq package. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: package/dnsmasq/Makefile === --- package/dnsmasq/Makefile(revision 31782) +++ package/dnsmasq/Makefile(working copy) @@ -32,7 +32,6 @@ define Package/dnsmasq/conffiles /etc/config/dhcp -/etc/dnsmasq.conf endef TARGET_CFLAGS += \ @@ -50,7 +49,6 @@ $(CP) $(PKG_INSTALL_DIR)/usr/sbin/dnsmasq $(1)/usr/sbin/ $(INSTALL_DIR) $(1)/etc/config $(INSTALL_DATA) ./files/dhcp.conf $(1)/etc/config/dhcp - $(INSTALL_DATA) ./files/dnsmasq.conf $(1)/etc/dnsmasq.conf $(INSTALL_DIR) $(1)/etc/init.d $(INSTALL_BIN) ./files/dnsmasq.init $(1)/etc/init.d/dnsmasq endef Index: package/dnsmasq/files/dnsmasq.conf === --- package/dnsmasq/files/dnsmasq.conf (revision 31782) +++ package/dnsmasq/files/dnsmasq.conf (working copy) @@ -1,37 +0,0 @@ -# Change the following lines if you want dnsmasq to serve SRV -# records. -# You may add multiple srv-host lines. -# The fields are name,target,port,priority,weight - -# A SRV record sending LDAP for the example.com domain to -# ldapserver.example.com port 289 -#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389 - -# Two SRV records for LDAP, each with different priorities -#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,1 -#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,2 - -# A SRV record indicating that there is no LDAP server for the domain -# example.com -#srv-host=_ldap._tcp.example.com - -# The following line shows how to make dnsmasq serve an arbitrary PTR -# record. This is useful for DNS-SD. -# The fields are name,target -#ptr-record=_http._tcp.dns-sd-services,New Employee Page._http._tcp.dns-sd-services - -# Change the following lines to enable dnsmasq to serve TXT records. -# These are used for things like SPF and zeroconf. -# The fields are name,text,text... - -#Example SPF. -#txt-record=example.com,v=spf1 a -all - -#Example zeroconf -#txt-record=_http._tcp.example.com,name=value,paper=A4 - -# Provide an alias for a local DNS name. Note that this _only_ works -# for targets which are names from DHCP or /etc/hosts. Give host -# bert another name, bertrand -# The fields are cname,target -#cname=bertand,bert ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] package/dnsmasq: remove obsolete /etc/dnsmasq.conf
Very well, I'll drop this. I missed the conf-file=/etc/dnsmasq.conf at the top of /var/etc/dnsmasq.conf. I'm still proposing the other four dnsmasq patches I sent to the list in a series earlier today. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: /etc/shadow should have mode 0600
Shadow passwords were enabled by default in r28936, but most of the benefit was not realized because the shadow file was allowed to be world-readable. This change sets /etc/shadow's mode to 0600 in the base-files package, and ensures that its permissions are not clobbered when building an image. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: include/image.mk === --- include/image.mk(revision 31782) +++ include/image.mk(working copy) @@ -142,7 +142,7 @@ define Image/mkfs/prepare/default # Use symbolic permissions to avoid clobbering SUID/SGID/sticky bits - - $(FIND) $(TARGET_DIR) -type f -not -perm +0100 -not -name 'ssh_host*' -print0 | $(XARGS) -0 chmod u+rw,g+r,o+r + - $(FIND) $(TARGET_DIR) -type f -not -perm +0100 -not -name 'ssh_host*' -not -name shadow -print0 | $(XARGS) -0 chmod u+rw,g+r,o+r - $(FIND) $(TARGET_DIR) -type f -perm +0100 -print0 | $(XARGS) -0 chmod u+rwx,g+rx,o+rx - $(FIND) $(TARGET_DIR) -type d -print0 | $(XARGS) -0 chmod u+rwx,g+rx,o+rx $(INSTALL_DIR) $(TARGET_DIR)/tmp Index: package/base-files/Makefile === --- package/base-files/Makefile (revision 31782) +++ package/base-files/Makefile (working copy) @@ -453,6 +453,7 @@ # from /etc/passwd, and adding on pw change data cut -d ':' -f 1-2 $(1)/etc/passwd $(1)/etc/shadow; \ $(SED) 's//:0:0:9:7:::/' $(1)/etc/shadow + chmod 0600 $(1)/etc/shadow $(VERSION_SED) \ $(1)/etc/banner \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] include/image.mk: /tmp should have mode 1777
On the off chance that the root filesystem's /tmp is used directly as a temporary directory instead of having a tmpfs mounted over it, it should have the sticky bit set. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: include/image.mk === --- include/image.mk(revision 31782) +++ include/image.mk(working copy) @@ -146,7 +146,7 @@ - $(FIND) $(TARGET_DIR) -type f -perm +0100 -print0 | $(XARGS) -0 chmod u+rwx,g+rx,o+rx - $(FIND) $(TARGET_DIR) -type d -print0 | $(XARGS) -0 chmod u+rwx,g+rx,o+rx $(INSTALL_DIR) $(TARGET_DIR)/tmp - chmod 0777 $(TARGET_DIR)/tmp + chmod 1777 $(TARGET_DIR)/tmp endef define Image/mkfs/prepare ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Upgrade nginx to 1.0.15
Changelog: http://nginx.org/en/CHANGES-1.0 This upgrade includes a fix for a security vulnerability, CVE-2012-2089. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: packages/net/nginx/Makefile === --- packages/net/nginx/Makefile (revision 31389) +++ packages/net/nginx/Makefile (working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=nginx -PKG_VERSION:=1.0.14 +PKG_VERSION:=1.0.15 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://nginx.org/download/ -PKG_MD5SUM:=019844e48c34952253ca26dd6e28c35c +PKG_MD5SUM:=17da4802209b83d9bebb0f0edd975dfc PKG_BUILD_PARALLEL:=1 PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Upgrade nginx to 1.0.14
Upgrade nginx to 1.0.14. Changelog: http://nginx.org/en/CHANGES-1.0 This upgrade includes a fix for a major security vulnerability, CVE-2012-1180. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: packages/net/nginx/Makefile === --- packages/net/nginx/Makefile (revision 31206) +++ packages/net/nginx/Makefile (working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=nginx -PKG_VERSION:=1.0.10 +PKG_VERSION:=1.0.14 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://nginx.org/download/ -PKG_MD5SUM:=930b297b00fa1018fb0a1dd3e6b7e17e +PKG_MD5SUM:=019844e48c34952253ca26dd6e28c35c PKG_BUILD_PARALLEL:=1 PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx: local mac support on the wndr3700?
Dave Taht wrote: [PATCH 4/4] Add local mac support to wndr3700 so as to be able to route not bridge The wndr3700 at least has no eth0 mac address and usually leverages the first wireless device's mac when in a bridged scenario. If, however, you want to route, and not bridge the interfaces, you need a unique mac address for it. This patch sets the local bit on the mac address pulled from the wireless chip and uses the resulting address for eth0. It’s unfortunate that in the default bridged configuration now, br-lan uses a MAC address with the locally-administered bit set. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: fix WNDR3x00 model detection
Detect the model name for /tmp/sysinfo/model based on 10 bytes at offset
56 in the art (caldata) mtd partition.
r29434 redid WNDR3x00 model detection, attempting to distinguish between
WNDR3700v2 and WNDR3800 by checking MemTotal in /proc/meminfo. However, it
contained a bug: it put the awk inside a $(...), with the result that all
WNDR3700v2 and WNDR3800 models would be reported as WNDR3800. This patch
checks the model name stored in the art partition, as is done by U-Boot
shipping on the WNDR3800. It has the likely advantage of working with
future models based on the WNDR3700 board. It also will not mis-detect
units on which people install more memory.
I have tested this patch on WNDR3700 (v1), WNDR3700v2, and WNDR3800.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
===
--- target/linux/ar71xx/base-files/lib/ar71xx.sh(revision 29471)
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh(working copy)
@@ -6,18 +6,22 @@
AR71XX_BOARD_NAME=
AR71XX_MODEL=
-ar71xx_get_mem_total() {
- $(awk '/MemTotal:/ {print($2)}' /proc/meminfo)
+ar71xx_get_mtd_offset_size_format() {
+ local mtd=$1
+ local offset=$2
+ local size=$3
+ local format=$4
+ local dev
+
+ dev=$(find_mtd_part $mtd)
+ [ -z $dev ] return
+
+ dd if=$dev bs=1 skip=$offset count=$size 2/dev/null | hexdump -v -e
1/1 \$format\
}
ar71xx_get_mtd_part_magic() {
- local part=$1
- local mtd
-
- mtd=$(find_mtd_part $part)
- [ -z $mtd ] return
-
- dd if=$mtd bs=4 count=1 2/dev/null | hexdump -v -n 4 -e '1/1 %02x'
+ local mtd=$1
+ ar71xx_get_mtd_offset_size_format $mtd 0 4 %02x
}
wndr3700_board_detect() {
@@ -33,13 +37,12 @@
machine=NETGEAR WNDR3700
;;
33373031)
- local mt
-
- mt=$(ar71xx_get_mem_total)
- if [ $mt -lt 65536 ]; then
+ local model
+ model=$(ar71xx_get_mtd_offset_size_format art 56 10 %c)
+ if [ -z $model ] || [ $model =
$'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' ]; then
machine=NETGEAR WNDR3700v2
else
- machine=NETGEAR WNDR3800
+ machine=NETGEAR $model
fi
;;
esac
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: fix WNDR3x00 factory image generation
Factory images for WNDR3700v2 and WNDR3800 should contain these model IDs for the device: field in their DNI tags, not WNDR3700. This regressed in r29434, which redid WNDR3x00 model detection. The sixth parameter to Image/Build/Netgear is only used as the -B argument to mkdniimg, which is used to set the device: field. In r29434, this was erroneously changed to be WNDR3700 for all models. The tools to flash factory images (U-Boot's TFTP server and the factory software's upgrade utility) may refuse to honor images with incorrect device: fields in their DNI tags. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: target/linux/ar71xx/image/Makefile === --- target/linux/ar71xx/image/Makefile (revision 29471) +++ target/linux/ar71xx/image/Makefile (working copy) @@ -795,8 +795,8 @@ wndr3700v2_mtdlayout=mtdparts=spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,1024k(kernel),14848k(rootfs),64k(art)ro,15872k@0x7(firmware) define Image/Build/Profile/WNDR3700 $(call Image/Build/Template/$(fs_64k)/$(1),Netgear,wndr3700,$(wndr3700_cmdline),$(wndr3700_mtdlayout),3700,WNDR3700, NA,) - $(call Image/Build/Template/$(fs_64k)/$(1),Netgear,wndr3700v2,$(wndr3700_cmdline),$(wndr3700v2_mtdlayout),3701,WNDR3700,,-H 29763654+16+64) - $(call Image/Build/Template/$(fs_64k)/$(1),Netgear,wndr3800,$(wndr3700_cmdline),$(wndr3700v2_mtdlayout),3701,WNDR3700,,-H 29763654+16+128) + $(call Image/Build/Template/$(fs_64k)/$(1),Netgear,wndr3700v2,$(wndr3700_cmdline),$(wndr3700v2_mtdlayout),3701,WNDR3700v2,,-H 29763654+16+64) + $(call Image/Build/Template/$(fs_64k)/$(1),Netgear,wndr3800,$(wndr3700_cmdline),$(wndr3700v2_mtdlayout),3701,WNDR3800,,-H 29763654+16+128) endef wr400n_cmdline=board=WRT400N console=ttyS0,115200 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] Fix trx_fixup
I concur that there's something wrong with mtd -j jffs write, as used by sysupgrade when preserving configuration. The CRC in the TRX header is computed before all writes that the CRC protects have completed. I've worked around this problem in my brcm47xx builds by running mtd fixtrx as part of the sysupgrade process. Your patch to fix this properly in mtd looks correct to me. On a related note, I haven't been able to understand why trx_fixup and mtd_fixtrx don't share an implementation, and why the mtd_fixtrx computes a CRC only over a single erase block. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image
Jonathan McCrohan wrote: Is there even a need to produce an oversize image warning? I'm not aware of any other architecture that refuses to build over a certain size. x86 being the obvious exception, but that is different because it doesn't target any particular device, but a whole architecture. (Either way, the rootfs size is customisable by the user.) Silently producing an unusable image can be pretty bad. It looks like juhosg has taken care of this in r29431. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wndr3800 machine name patch
I just had a chance to flash a WNDR3800 with an image that contains this “machine name” patch (post-r29326). It's broken in two ways that I can see so far. These are regressions. The WNDR3800 images that used board=WNDR3700v2 worked properly in these cases. It remains my recommendation that this patch be backed out. The bugs I've discovered are: 1. The power LED is broken. Once OpenWRT begins booting, the power LED turns off, and stays off. (target/linux/ar71xx/base-files/etc/diag.sh). 2. The network switch configuration is broken. Each port is in its own VLAN. There is no traffic passed between ports. (target/linux/ar71xx/base-files/etc/defconfig/wndr3800). I don't know how many other similar bugs there are, caused by other locations where you neglected to account for the new machine name and resultant ar71xx_board_name (target/linux/ar71xx/base-files/lib/ar71xx.sh). While it would be a simple matter to fix both of these, it would only reinforce the misconception that there are differences between these boards, when in fact there are none. I do believe it would be best to just back out this patch. Users who need a way to distinguish between WNDR3700v2 and WNDR3800 systems that are running are advised to read the art/caldata partition as previously mentioned. A WNDR3800 contains the string WNDR3800 at the caldata/art partition at offset 56, length 10. Assuming caldata/art is on mtd5, you can obtain this by running |hexdump -v -e '/1 %c' -s 56 -n 10 /dev/mtd5|. A WNDR3700v2 or WNDR3700 just contains 0xff bytes at this location, so hexdump will give back ten question marks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image
Jonathan Bennett wrote: This patch seems like a really good idea for the ar71xx family. What sorts of problems are preventing this from being implemented? As small as it sounds, an extra 192k would be really useful on quite a few routers. I don't know of any actual problems with the patch. When I originally proposed the patch on this list, Dave Taht was concerned that it might not leave enough headroom to field-update the kernel with a larger one (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012026.html), although my position is that this is what the configuration-preserving sysupgrade feature is for (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012033.html). My patch is specific to WNDR3700 (and derivatives including WNDR3700v2 and WNDR3800), not the entire ar71xx family. I've been keeping the patch up-to-date (https://dev.openwrt.org/ticket/8781) and have been using it in all of my images for nearly a year. I know that others have been using this patch as well, and it's present in at least one community binary build. In current trunk images, the savings is only 128kB. In the time since I originally wrote this patch, the kernel's grown into another erase block. Someone else suggested detecting the beginning of the rootfs as is done on another target (https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches/201-owrt-mtd_uimage_split.patch), although I'm not very excited about scanning for a magic number in this manner. It's too fragile. It may be possible to determine the kernel size by other means, which would make it possible for the kernel to calculate the kernel-rootfs split at runtime more reliably. Unfortunately, detecting the kernel partition size in this manner would be board-specific, because different boards load the kernel in different ways. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wndr3800 machine name patch
Gabor Juhos wrote: 2011.11.16. 21:20 keltezéssel, Petri Rosenström írta: This fixes the machine name in /proc/cpuinfo and luci status page machine name. Signed-off-by: Petri Rosenström petri.rosenst...@gmail.com Applied, thanks! I don't think this patch is a great idea. There are no differences between the boards in the WNDR3700v2 and WNDR3800. The only hardware difference is that the latter has more RAM. I don't think that baking this information into the OpenWRT image or differentiating between the two models in this way serves any useful purpose. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wndr3800 machine name patch
Petri Rosenström wrote: I think it is useful because it adds the specific board information about WNDR3800 (e.g. the name WNDR3800 on status page or /proc/cpuinfo show correct board name). I think that this information is important and it should be available. Since you can flash a WNDR3700v2 with a WNDR3800 image and vice-versa, and the name is simply baked into the image you chose to flash with no other differences between the two, it seems pointless. btw. Do you (Mark) own the both devices? Have you (Mark) checked that they are the same (only RAM diff)? I have *only* seen claims on some forums and I only own a wndr3800 so I can't say for sure. It seems like they are. But it would be nice to know for sure. If it's terribly important, you can detect the difference between 3700v2 and 3800 at runtime. The data's in the art/caldata area. The WNDR3800 U-Boot source has the details. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image
Dave Taht wrote: Awesome. However I'd like to somehow make for fully field-upgradable kernels for this device (how to do that?), and reserving 64k strikes me as too small to account for future growth. It doesn't reserve 64kB. It doesn't really reserve anything at all. There can be as little as zero bytes of free space in the kernel mtd partition. The point is to pack it in as tightly as possible, leaving more space for the rootfs. I didn't think that field-upgradability by replacing only the contents of the kernel mtd partition was a design goal. Considering that it's likely that a kernel upgrade will also require a /lib/modules upgrade, I'm not sure it's even worthwhile to make it a design goal. Field- upgradability is addressed by sysupgrade, which is able to replace the entire firmware image (including the kernel and rootfs, with /lib/modules) while retaining configuration files and other files marked to be saved through the upgrade. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image
This replaces the fixed flash layout currently used on the WNDR3700
family with one whose mtd partition sizes are computed dynamically.
Rather than reserving 1MB for the kernel regardless of its actual space
requirements, this computes an appropriate size for the kernel, rounded
up to a 64kB erase block boundary. The space freed up by the kernel is
available for use by the on-flash rootfs. In current trunk builds, this
makes an extra 192kB available for user purposes.
I've been using this patch since February when I first wrote it, and so
have others. Fixes https://dev.openwrt.org/ticket/8781.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: target/linux/ar71xx/image/Makefile
===
--- target/linux/ar71xx/image/Makefile (revision 27926)
+++ target/linux/ar71xx/image/Makefile (working copy)
@@ -42,13 +42,13 @@
define PatchKernelLzma
cp $(KDIR)/vmlinux $(KDIR)/vmlinux-$(1)
- $(STAGING_DIR_HOST)/bin/patch-cmdline $(KDIR)/vmlinux-$(1) '$(strip
$(2))'
+ $(STAGING_DIR_HOST)/bin/patch-cmdline $(KDIR)/vmlinux-$(1) $(strip
$(2))
$(call CompressLzma,$(KDIR)/vmlinux-$(1),$(KDIR)/vmlinux-$(1).bin.lzma)
endef
define PatchKernelGzip
cp $(KDIR)/vmlinux $(KDIR)/vmlinux-$(1)
- $(STAGING_DIR_HOST)/bin/patch-cmdline $(KDIR)/vmlinux-$(1) '$(strip
$(2))'
+ $(STAGING_DIR_HOST)/bin/patch-cmdline $(KDIR)/vmlinux-$(1) $(strip
$(2))
gzip -9 -c $(KDIR)/vmlinux-$(1) $(KDIR)/vmlinux-$(1).bin.gz
endef
@@ -287,29 +287,72 @@
rm $(KDIR)/image.tmp
endef
-define Image/Build/Netgear
- $(call MkuImageLzma,$(2),$(3) $($(4)))
- mkdir -p $(KDIR)/wndr3700/image
+define Image/Build/Netgear/Build_uImage
+ $(call MkuImageLzma,$(1),$(2) $(3))
+ -rm -rf $(KDIR)/$(1)
+ mkdir -p $(KDIR)/$(1)/image
$(STAGING_DIR_HOST)/bin/wndr3700 \
- $(KDIR)/vmlinux-$(2).uImage \
- $(KDIR)/wndr3700/image/uImage \
- $(5)
+ $(KDIR)/vmlinux-$(1).uImage \
+ $(KDIR)/$(1)/image/uImage \
+ $(4)
$(STAGING_DIR_HOST)/bin/mksquashfs-lzma \
- $(KDIR)/wndr3700 $(KDIR)/vmlinux-$(2).uImage.squashfs.tmp \
+ $(KDIR)/$(1) $(KDIR)/vmlinux-$(1).uImage.squashfs.tmp \
-nopad -noappend -root-owned -be
- -rm -rf $(KDIR)/wndr3700
+ -rm -rf $(KDIR)/$(1)
mkimage -A mips -O linux -T filesystem -C none \
-a 0xbf07 -e 0xbf07 \
-n 'MIPS OpenWrt Linux-$(LINUX_VERSION)' \
- -d $(KDIR)/vmlinux-$(2).uImage.squashfs.tmp \
- $(KDIR)/vmlinux-$(2).uImage.squashfs.tmp2
+ -d $(KDIR)/vmlinux-$(1).uImage.squashfs.tmp \
+ $(KDIR)/vmlinux-$(1).uImage.squashfs.tmp2
$(STAGING_DIR_HOST)/bin/wndr3700 \
- $(KDIR)/vmlinux-$(2).uImage.squashfs.tmp2 \
- $(KDIR)/vmlinux-$(2).uImage.squashfs \
- $(5)
- -rm -f $(KDIR)/vmlinux-$(2).uImage.squashfs.tmp*
+ $(KDIR)/vmlinux-$(1).uImage.squashfs.tmp2 \
+ $(KDIR)/vmlinux-$(1).uImage.squashfs \
+ $(4)
+ -rm -f $(KDIR)/vmlinux-$(1).uImage.squashfs.tmp*
+endef
+
+define Image/Build/Netgear/Estimate_uImage
+ $(call Image/Build/Netgear/Build_uImage,$(1)_est,$(2),$(3),$(4))
( \
- dd if=$(KDIR)/vmlinux-$(2).uImage.squashfs bs=1024k conv=sync; \
+ set -e; \
+ kk=`echo '$(3)' | sed -e 's/.*[:,]\([0-9]*\)k(kernel).*/\1/'`; \
+ rk=`echo '$(3)' | sed -e 's/.*[:,]\([0-9]*\)k(rootfs).*/\1/'`; \
+ let 'tk = kk + rk'; \
+ s=`stat -c'%s' '$(KDIR)/vmlinux-$(1)_est.uImage.squashfs'`; \
+ c=`echo '$(3)' | wc -c`; \
+ let 'kk = (((s + c) / (64 * 1024) + 1) * 64)'; \
+ let 'rk = tk - kk'; \
+ echo '$(3)' | sed -e s/[0-9]*k(kernel)/{kk}k(kernel)/ \
+ -e s/[0-9]*k(rootfs)/{rk}k(rootfs)/ \
+ '$(KDIR)/$(1)_mtdparts'; \
+ let 'k = kk * 1024'; \
+ echo {k} '$(KDIR)/$(1)_kernel_maxsize'; \
+ let 'r = rk * 1024'; \
+ echo {r} '$(KDIR)/$(1)_rootfs_maxsize'; \
+ )
+ -rm -f $(KDIR)/vmlinux-$(1)_est \
+ $(KDIR)/vmlinux-$(1)_est.bin.lzma \
+ $(KDIR)/vmlinux-$(1)_est.uImage \
+ $(KDIR)/vmlinux-$(1)_est.uImage.squashfs
+endef
+
+define Image/Build/Netgear
+ $(call Image/Build/Netgear/Estimate_uImage,$(2),$(3),$(4),$(5))
+ $(call Image/Build/Netgear/Build_uImage,$(2),$(3),`cat
$(KDIR)/$(2)_mtdparts`,$(5))
+ if [ `stat -c%s '$(KDIR)/vmlinux-$(2).uImage.squashfs'` -gt \
+`cat '$(KDIR)/$(2)_kernel_maxsize'` ]; then \
+echo $(KDIR)/vmlinux-$(2).uImage.squashfs is too big 2; \
+ false
[OpenWrt-Devel] [PATCH v2] toolchain/gcc: upgrade Linaro GCC to 4.5-2011.05-0
This is identical to the patch previously submitted on June 3, except this
one is embedded in the body of the message instead of being presented as a
distinct MIME attachment.
I've used the updated toolchain on both ar71xx and bcm47xx.
--
toolchain/gcc: upgrade Linaro GCC to 4.5-2011.05-0
Signed-off-by: Mark Mentovai m...@moxienet.com
--
Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
===
--- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
(revision 27096)
+++ toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch
(working copy)
@@ -1,18 +0,0 @@
-https://bugs.launchpad.net/gcc-linaro/+bug/728315
-https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/009847.html
-
a/gcc/ee.c
-+++ b/gcc/ee.c
-@@ -209,7 +209,11 @@
-
- *regno = REGNO (reg);
-
-- if (paradoxical_subreg_p (use))
-+ /* Non-paradoxical SUBREGs of promoted vars guarantee that the
-+ upper (elided) bits of the inner register have a particular value.
-+ For our purposes, such SUBREGs act as a full reference to the
-+ inner register. */
-+ if (paradoxical_subreg_p (use) || SUBREG_PROMOTED_VAR_P (use))
- *size = GET_MODE_BITSIZE (GET_MODE (reg));
- else
- *size = subreg_lsb (use) + GET_MODE_BITSIZE (GET_MODE (use));
Index: toolchain/gcc/patches/linaro/993-arm_insn-opinit-RTX_CODE-fixup.patch
===
--- toolchain/gcc/patches/linaro/993-arm_insn-opinit-RTX_CODE-fixup.patch
(revision 27096)
+++ toolchain/gcc/patches/linaro/993-arm_insn-opinit-RTX_CODE-fixup.patch
(working copy)
@@ -1,6 +1,6 @@
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
-@@ -43,10 +43,10 @@ extern unsigned int arm_dbx_register_num
+@@ -44,10 +44,10 @@ extern unsigned int arm_dbx_register_num
extern void arm_output_fn_unwind (FILE *, bool);
Index: toolchain/gcc/patches/linaro/850-use_shared_libgcc.patch
===
--- toolchain/gcc/patches/linaro/850-use_shared_libgcc.patch(revision 27096)
+++ toolchain/gcc/patches/linaro/850-use_shared_libgcc.patch(working copy)
@@ -1,9 +1,9 @@
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
-@@ -72,10 +72,6 @@
- #undef LINK_SPEC
- #define LINK_SPEC LINUX_TARGET_LINK_SPEC BE8_LINK_SPEC TARGET_FIX_V4BX_SPEC
-
+@@ -95,10 +95,6 @@
+ #define ENDFILE_SPEC \
+ LINUX_OR_ANDROID_LD (LINUX_TARGET_ENDFILE_SPEC, ANDROID_ENDFILE_SPEC)
+
-/* Use the default LIBGCC_SPEC, not the version in linux-elf.h, as we
- do not use -lfloat. */
-#undef LIBGCC_SPEC
@@ -24,7 +24,7 @@
#define LINUX_TARGET_LINK_SPEC %{h*} %{version:-v} \
--- a/gcc/config/linux.h
+++ b/gcc/config/linux.h
-@@ -104,6 +104,10 @@
+@@ -116,6 +116,10 @@
#define USE_LD_AS_NEEDED 1
#endif
@@ -33,8 +33,8 @@
+#endif
+
/* Determine which dynamic linker to use depending on whether GLIBC or
-uClibc is the default C library and whether -muclibc or -mglibc has
-been passed to change the default. */
+uClibc or Bionic is the default C library and whether
+-muclibc or -mglibc or -mbionic has been passed to change the default. */
--- a/gcc/mkmap-symver.awk
+++ b/gcc/mkmap-symver.awk
@@ -132,5 +132,5 @@
Index: toolchain/gcc/patches/linaro/840-armv4_pass_fix-v4bx_to_ld.patch
===
--- toolchain/gcc/patches/linaro/840-armv4_pass_fix-v4bx_to_ld.patch
(revision 27096)
+++ toolchain/gcc/patches/linaro/840-armv4_pass_fix-v4bx_to_ld.patch
(working copy)
@@ -1,6 +1,6 @@
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
-@@ -63,10 +63,14 @@
+@@ -63,12 +63,16 @@
#undef GLIBC_DYNAMIC_LINKER
#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
@@ -11,8 +11,10 @@
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
#undef LINK_SPEC
--#define LINK_SPEC LINUX_TARGET_LINK_SPEC BE8_LINK_SPEC
-+#define LINK_SPEC LINUX_TARGET_LINK_SPEC BE8_LINK_SPEC TARGET_FIX_V4BX_SPEC
-
- /* Use the default LIBGCC_SPEC, not the version in linux-elf.h, as we
-do not use -lfloat. */
+ #define LINK_SPEC BE8_LINK_SPEC
\
+ LINUX_OR_ANDROID_LD (LINUX_TARGET_LINK_SPEC,
\
+- LINUX_TARGET_LINK_SPEC ANDROID_LINK_SPEC)
++ LINUX_TARGET_LINK_SPEC ANDROID_LINK_SPEC)\
+
+ #undef CC1_SPEC
+ #define CC1_SPEC \
Index: toolchain/gcc/patches/linaro/910-mbsd_multi.patch
===
--- toolchain/gcc/patches/linaro/910-mbsd_multi.patch (revision 27096)
+++ toolchain/gcc/patches/linaro/910-mbsd_multi.patch (working copy
[OpenWrt-Devel] [PATCH] toolchain/gcc: upgrade Linaro GCC to 4.5-2011.05-0
toolchain/gcc: upgrade Linaro GCC to 4.5-2011.05-0 Signed-off-by: Mark Mentovai m...@moxienet.com linaro_4.5-2011.05-0.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] WNDR3700v2: Stop producing -NA factory images, tag factory images with hd_id
NETGEAR doesn’t produce a distinct North American image for WNDR3700v2, they use the same image worldwide. This is a change from earlier models such as WNDR3700 (v1). NETGEAR's v2 images now contain an hd_id parameter, as well. All observed WNDR3700v2, WNDR3800, and WNDRMAC images use 29763654+16+64 as their hd_id value. This patch changes the OpenWrt WNDR3700v2 factory image generation to stop producing the extraneous -NA version and to tag the image with the same hd_id used in NETGEAR's images. There is no change to WNDR3700 (v1) image generation, as NETGEAR continues to produce distinct -NA and worldwide images, neither of which are tagged with hd_id. Signed-off-by: Mark Mentovai m...@moxienet.com wndr3700v2_images.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] Reclaim unused space in WNDR3700 image (and maybe others?)
Gábor- I’d like your thoughts (and others’) on my proposed patch at https://dev.openwrt.org/ticket/8781 Currently, the WNDR3700 images reserve 1MB for the kernel, whether or not the kernel is actually anywhere near that size. It can be smaller, in which case space is wasted, or it can in theory be larger, in which case a broken image would be produced. Given that a 64kB block size is in use, I find that my kernels fit neatly in 832kB, which frees up 192kB of flash for other purposes. That’s a decent improvement on a system that might have as little as 8MB of flash. I realize that this approach can apply to more than just the WNDR3700. Certainly it’d work for some other members of the ar71xx family, and probably other targets as well. I haven’t tried to solve the problem in a more generic way yet. Do you think that this is something worth pursuing (or checking in as-is and iterating on) or am I doomed to continue carrying this as a local patch? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Rationalize ieee80211d configuration
(This is a follow-up to the thread entitled r26765 (Beacon should include a Country Information Element) started on April 27.) nbd pointed out that the patch jow and I cooked up treated ieee80211d as a per-vif setting, but hostapd deals with it globally. While each vif can theoretically have its own setting, hostapd doesn't currently work this way. This was a problem with the existing ieee80211d UCI parameter as well. This patch removes the old per-vif ieee80211d setting and moves it onto the device, renaming (and replacing) the country_ie setting added in r26765. This resolves the discrepancy between the two places that ieee80211d could be set. Signed-off-by: Mark Mentovai m...@moxienet.com ieee80211d.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] r26765 (Beacon should include a Country Information Element)
Jo-Philipp Wich wrote:
Here's my proposal:
I like the outcome but I find the logic a bit confusing. ${country_ie}
starts out as the value of the country parameter on the wifi-device
(empty or a country string), but then becomes either 0 or 1, a boolean
that controls enabling the feature in hostapd. Then, ${ieee80211d} is
introduced, which pretty much does the same thing as ${country_ie} in
that it acts as a boolean to determine whether hostapd should be
configured with ieee80211d after UCI is consulted. Why was
${country_ie} the repurposed variable instead of ${ieee80211d}?
This would have the same effect but wouldn’t recycle ${country_ie} and
would instead reuse ${ieee80211d} as both the default for
config_get_bool and the final variable to hold the result. In case
anyone needs access to country in the future, it remains available in
its own variable.
How about this (untested) version? I think it’s a little cleaner.
Index: package/hostapd/files/hostapd.sh
===
--- package/hostapd/files/hostapd.sh(revision 26774)
+++ package/hostapd/files/hostapd.sh(working copy)
@@ -136,9 +136,14 @@
config_get ssid $vif ssid
config_get bridge $vif bridge
- config_get ieee80211d $vif ieee80211d
config_get iapp_interface $vif iapp_interface
+ config_get country $device country
+ [ -n $country ] ieee80211d=1 || ieee80211d=0
+
+ config_get_bool ieee80211d $vif ieee80211d $ieee80211d
+ [ $ieee80211d = 0 ] ieee80211d=
+
config_get_bool wps_pbc $vif wps_pushbutton 0
config_get_bool wps_label $vif wps_label 0
Index: package/mac80211/files/lib/wifi/mac80211.sh
===
--- package/mac80211/files/lib/wifi/mac80211.sh (revision 26774)
+++ package/mac80211/files/lib/wifi/mac80211.sh (working copy)
@@ -36,11 +36,6 @@
}
}
- local country_ie=0
- [ -n $country ] country_ie=1
- config_get_bool country_ie $device country_ie $country_ie
- [ $country_ie -gt 0 ] append base_cfg ieee80211d=1 $N
-
config_get macfilter $vif macfilter
case $macfilter in
allow)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] toolchain/gcc (linaro): fix extension elimination optimization
This applies Richard Sandiford's patch for Linaro GCC as an alternative to disabling the Linaro-specific extension elimination optimization altogether. Original patch: https://bugs.launchpad.net/gcc-linaro/+bug/728315 Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch === --- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch (revision 0) +++ toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch (revision 0) @@ -0,0 +1,18 @@ +https://bugs.launchpad.net/gcc-linaro/+bug/728315 +https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/009847.html + +--- a/gcc/ee.c b/gcc/ee.c +@@ -209,7 +209,11 @@ + + *regno = REGNO (reg); + +- if (paradoxical_subreg_p (use)) ++ /* Non-paradoxical SUBREGs of promoted vars guarantee that the ++ upper (elided) bits of the inner register have a particular value. ++ For our purposes, such SUBREGs act as a full reference to the ++ inner register. */ ++ if (paradoxical_subreg_p (use) || SUBREG_PROMOTED_VAR_P (use)) + *size = GET_MODE_BITSIZE (GET_MODE (reg)); + else + *size = subreg_lsb (use) + GET_MODE_BITSIZE (GET_MODE (use)); Index: toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch === --- toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch (revision 25854) +++ toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch (working copy) @@ -1,11 +0,0 @@ a/gcc/opts.c -+++ b/gcc/opts.c -@@ -906,7 +906,7 @@ decode_options (unsigned int argc, const - flag_tree_if_to_switch_conversion = opt2; - flag_ipa_cp = opt2; - flag_ipa_sra = opt2; -- flag_ee = opt2; -+ flag_ee = 0; - - /* Track fields in field-sensitive alias analysis. */ - set_param_value (max-fields-for-field-sensitive, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] toolchain/gcc (linaro): fix extension elimination optimization
(Resending, the original attempt wrapped unexpectedly.) This applies Richard Sandiford's patch for Linaro GCC as an alternative to disabling the Linaro-specific extension elimination optimization altogether. Original patch: https://bugs.launchpad.net/gcc-linaro/+bug/728315 Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch === --- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch (revision 0) +++ toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch (revision 0) @@ -0,0 +1,18 @@ +https://bugs.launchpad.net/gcc-linaro/+bug/728315 +https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/009847.html + +--- a/gcc/ee.c b/gcc/ee.c +@@ -209,7 +209,11 @@ + + *regno = REGNO (reg); + +- if (paradoxical_subreg_p (use)) ++ /* Non-paradoxical SUBREGs of promoted vars guarantee that the ++ upper (elided) bits of the inner register have a particular value. ++ For our purposes, such SUBREGs act as a full reference to the ++ inner register. */ ++ if (paradoxical_subreg_p (use) || SUBREG_PROMOTED_VAR_P (use)) + *size = GET_MODE_BITSIZE (GET_MODE (reg)); + else + *size = subreg_lsb (use) + GET_MODE_BITSIZE (GET_MODE (use)); Index: toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch === --- toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch (revision 25854) +++ toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch (working copy) @@ -1,11 +0,0 @@ a/gcc/opts.c -+++ b/gcc/opts.c -@@ -906,7 +906,7 @@ decode_options (unsigned int argc, const - flag_tree_if_to_switch_conversion = opt2; - flag_ipa_cp = opt2; - flag_ipa_sra = opt2; -- flag_ee = opt2; -+ flag_ee = 0; - - /* Track fields in field-sensitive alias analysis. */ - set_param_value (max-fields-for-field-sensitive, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] toolchain/gcc (linaro): fix extension elimination optimization
(Third time's the charm? Sorry for the spam.) This applies Richard Sandiford's patch for Linaro GCC as an alternative to disabling the Linaro-specific extension elimination optimization altogether. Original patch: https://bugs.launchpad.net/gcc-linaro/+bug/728315 Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch === --- toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch (revision 0) +++ toolchain/gcc/patches/linaro/860-fix_extension_elimination.patch (revision 0) @@ -0,0 +1,18 @@ +https://bugs.launchpad.net/gcc-linaro/+bug/728315 +https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/009847.html + +--- a/gcc/ee.c b/gcc/ee.c +@@ -209,7 +209,11 @@ + + *regno = REGNO (reg); + +- if (paradoxical_subreg_p (use)) ++ /* Non-paradoxical SUBREGs of promoted vars guarantee that the ++ upper (elided) bits of the inner register have a particular value. ++ For our purposes, such SUBREGs act as a full reference to the ++ inner register. */ ++ if (paradoxical_subreg_p (use) || SUBREG_PROMOTED_VAR_P (use)) + *size = GET_MODE_BITSIZE (GET_MODE (reg)); + else + *size = subreg_lsb (use) + GET_MODE_BITSIZE (GET_MODE (use)); Index: toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch === --- toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch (revision 25854) +++ toolchain/gcc/patches/linaro/860-disable_extension_elimination.patch (working copy) @@ -1,11 +0,0 @@ a/gcc/opts.c -+++ b/gcc/opts.c -@@ -906,7 +906,7 @@ decode_options (unsigned int argc, const - flag_tree_if_to_switch_conversion = opt2; - flag_ipa_cp = opt2; - flag_ipa_sra = opt2; -- flag_ee = opt2; -+ flag_ee = 0; - - /* Track fields in field-sensitive alias analysis. */ - set_param_value (max-fields-for-field-sensitive, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] hostapd: work around Linaro GCC 4.5.2 bad codegen for MIPS
Felix Fietkau wrote: Scratch that, got confused by the delay slot for a second there :) I see the code that adds the wrong bits now, I wonder if there's something wrong with signed vs unsigned type propagation... I'll let you know when I find out more about this. I agree that signed/unsigned confusion may play a role. Things fall apart when Linaro emits li v0,-16384; -16384 is 0xc000. Everything would be fine if the immediate value were 0xc000 instead. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] hostapd: work around Linaro GCC 4.5.2 bad codegen for MIPS
Felix Fietkau wrote: Actually, it emits -16384 in both the working and non-working case, I think what makes the difference of working vs non-working is this: Broken: (0xc000 is in v0) - e8:00021a02srl v1,v0,0x8 - ec:00021200sll v0,v0,0x8 Working: (0xc000 is in v1) + e8:7c623a00ext v0,v1,0x8,0x8 + ec:00031a00sll v1,v1,0x8 using ext instead of srl prevents the extra bits from spilling over. Sure. I was looking at the assembly emitted by the other compilers I tested. None of those even ever use -16384 (0xc000). They all simply OR in 0xc000 (as an immediate value). I’m in touch with Linaro about this bug, so maybe we’ll get some traction without having to commit my workaround patch. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mac80211: allow AP configuration of beacon interval, DTIM period, maximum permissible STA listen interval, and basic rates
This introduces beacon_int and basic_rate (per wifi-device), and
dtim_period and max_listen_int (per wifi-iface) for mac80211. These
configure the beacon interval, basic rate specification, DTIM period
(one DTIM per this many beacon frames), and maximum listen interval
that a STA will be permitted to associate with. All of the new
settings are optional; if they're absent, the existing hostapd (or, in
the case of basic_rate, driver) defaults will be used.
The existing bintval property only used for type adhoc is moved from
wifi-iface to wifi-device, and is renamed to beacon_interval because
bintval isn't a great name. The beacon interval is property of the
wifi-device; while the choice between wifi-device and wifi-iface may
not be relevant with an adhoc network, there's no reason to configure
the same property one way for type adhoc and another for type ap. This
change isn't expected to cause many problems, as bintval was added
recently, in r25111.
Similarly, the list of basic rates, also added for type adhoc in
r25111, is a property of the device and not the interface. Further, it
ought to be represented in UCI as a list, not a string dependent on
the format that iw uses. I’ve moved it onto the device, renamed it to
basic_rate, and made it configurable for APs via hostapd. Finally, I
adapted it to use the same kb/s representation as mcast_rate; there's
precedent for this format in that it's also how madwifi interprets
mcast_rate.
Neither bintval nor basicrates were ever documented in the UCI
wireless configuration page on the wiki. When this change is
committed, I'll update the documentation as needed.
Signed-off-by: Mark Mentovai m...@moxienet.com
---
Index: package/mac80211/files/lib/wifi/mac80211.sh
===
--- package/mac80211/files/lib/wifi/mac80211.sh (revision 25834)
+++ package/mac80211/files/lib/wifi/mac80211.sh (working copy)
@@ -13,6 +13,8 @@
config_get country $device country
config_get hwmode $device hwmode
config_get channel $device channel
+ config_get beacon_int $device beacon_int
+ config_get basic_rate_list $device basic_rate
config_get_bool noscan $device noscan
[ -n $channel -a -z $hwmode ] wifi_fixup_hwmode $device
[ $channel = auto ] channel=
@@ -51,6 +53,16 @@
echo $mac $macfile
done
}
+
+ local br brval brstr
+ [ -n $basic_rate_list ] {
+ for br in $basic_rate_list; do
+ brval=$(($br / 100))
+ [ -n $brstr ] brstr=$brstr
+ brstr=$brstr$brval
+ done
+ }
+
cat $cfgfile EOF
ctrl_interface=/var/run/hostapd-$phy
driver=nl80211
@@ -92,8 +104,10 @@
tx_queue_data0_burst=1.5
${hwmode:+hw_mode=$hwmode}
${channel:+channel=$channel}
+${beacon_int:+beacon_int=$beacon_int}
${country:+country_code=$country}
${noscan:+noscan=$noscan}
+${brstr:+basic_rates=$brstr}
$base_cfg
EOF
@@ -127,6 +141,8 @@
local macaddr hidden maxassoc wmm
config_get macaddr $vif macaddr
config_get maxassoc $vif maxassoc
+ config_get dtim_period $vif dtim_period
+ config_get max_listen_int $vif max_listen_int
config_get_bool hidden $vif hidden 0
config_get_bool wmm $vif wmm 1
cat /var/run/hostapd-$phy.conf EOF
@@ -134,6 +150,8 @@
wmm_enabled=$wmm
bssid=$macaddr
ignore_broadcast_ssid=$hidden
+${dtim_period:+dtim_period=$dtim_period}
+${max_listen_int:+max_listen_interval=$max_listen_int}
${maxassoc:+max_num_sta=$maxassoc}
EOF
}
@@ -390,8 +408,8 @@
adhoc)
config_get bssid $vif bssid
config_get ssid $vif ssid
- config_get bintval $vif bintval
- config_get basicrates $vif basicrates
+ config_get beacon_int $device
beacon_int
+ config_get basic_rate_list $device
basic_rate
config_get encryption $vif encryption
config_get key $vif key 1
config_get mcast_rate $vif mcast_rate
@@ -416,6 +434,17 @@
esac
}
+ local br brval brsub brstr
+ [ -n $basic_rate_list ] {
+ for br in $basic_rate_list; do
+ brval=$(($br / 1000))
+ brsub=$((($br / 100) %
10))
+ [ $brsub -gt 0 ]
brval=$brval.$brsub
Re: [OpenWrt-Devel] [PATCH] hostapd: work around Linaro GCC 4.5.2 bad codegen for MIPS
I received a request for more information, so in case anyone else is interested, here’s what was happening. The problem occurs in hostapd src/ap/ieee802_11.c’s send_assoc_resp. The C statement that triggers the compiler bug is reply-u.assoc_resp.aid = host_to_le16((sta ? sta-aid : 0) | BIT(14) | BIT(15)); Here’s the code I see generated by the Linaro compiler, along with annotation, and some sample values assuming that sta-aid is 1. In this case, we’d want to store 1 in 28($18) and 0xc0 in 29($18), but that’s not what happens. beq $17,$0,$L3# $17 is sta, if !sta, branch to $L3 li $2,49152 # $2 = 49152 = 0xc000 (branch delay slot) lhu $3,14($17)# $3 = sta-aid # $3 = 0x0001 li $2,-16384 # $2 = -16384 = 0xc000# $2 = 0xc000 or $2,$3,$2 # $2 = sta-aid | 0xc000 # $2 = 0xc001 $L3: srl $3,$2,8 # $3 = $2 8# $3 = 0x00c0 sll $2,$2,8 # $2 = $2 8# $2 = 0xffc00100 or $2,$3,$2 # $2 = $3 | $2# $2 = 0xffc0 andi$2,$2,0x # $2 = $2 0x# $2 = 0xffc0 srl $3,$2,8 # $3 = $2 8# $3 = 0x00ff move$4,$16 addiu $5,$18,30 sb $3,28($18)# first byte of reply-u.assoc_resp.aid = # low byte of $3 = 0xff jal hostapd_eid_supp_rates sb $2,29($18)# second byte of reply-u.assoc_resp.aid = # low byte of $2 = 0xc0 Linaro’s Richard Sandiford is on the case and diagnosed the problem as Linaro’s new extension-elimination optimization. Felix checked in OpenWrt r25834 which disables this optimization unless explicitly requested. For OpenWrt, this requires a toolchain rebuild. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac80211: allow AP configuration of beacon interval, DTIM period, maximum permissible STA listen interval, and basic rates
bjorn.smed...@venatech.se: Wouldn't it make more sense to configure beacon interval per wifi-iface? This is how mac80211 does it and there is at least talk about supporting different beacon intervals for different ap vifs with ath9k. It’s configured via hostapd, which only supports the beacon interval being configured on the wifi-device. Is there another way to push the beacon into mac80211 from user space? iw doesn’t seem to be able to do it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] hostapd: work around Linaro GCC 4.5.2 bad codegen for MIPS
mips-openwrt-linux-uclibc-gcc 4.5.2 (Linaro GCC 4.5-2011.02-0), the default compiler for MIPS since r25708, miscompiles send_assoc_resp in hostapd's src/ap/ieee802_11.c. Specifically, the association ID (AID) field in the association response frame is set improperly. This gives a connected STA the wrong idea of what its AID is, causing it to consult the wrong bit in the traffic information map (TIM) when determining whether the AP has any data buffered for it. A STA with an aggressive power saving policy might not switch out of power saving mode until it has reason to transmit; this will cause delayed or dropped frame delivery to the STA. IEEE 802.11-2007 7.3.1.8 says that the association ID (AID) is transmitted in a 16-bit field, of which the high-order 2 bits must be set to 1, and the low-order 14 bits are significant and represent the actual AID value. The code generation bug causes the low-order 8 bits of the field to always be set to 1. For example, AID 1 would normally be transmitted in an association response frame as 0x01 0xc0 (in little-endian byte order); this bug causes it to be transmitted as 0xff 0xc0. The STA would consult bit 255 instead of bit 1 in the TIM. Splitting the AID value out into its own temporary variable is enough to avoid the bad code generation. I only experienced a problem with the AID field, but chose to make the same change for the capability information field for good measure. I can provide annotated examples of code generation if anyone's interested. In addition to 4.5.2 (Linaro GCC 4.5-2011.02-0), I tested 4.3.3 (CodeSourcery), 4.4.5 (GCC), and mainline 4.5.2 (GCC). None of the other compilers miscompiled this code. Since this bug is restricted to Linaro GCC 4.5 targeting MIPS, and I doubt many others are targeting MIPS with this compiler, I'm not sending this patch upstream to hostapd at this point. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: package/hostapd/patches/001-mips_linaro_gcc45_codegen.patch === --- package/hostapd/patches/001-mips_linaro_gcc45_codegen.patch (revision 0) +++ package/hostapd/patches/001-mips_linaro_gcc45_codegen.patch (revision 0) @@ -0,0 +1,18 @@ +--- a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c +@@ -837,11 +837,11 @@ + + send_len = IEEE80211_HDRLEN; + send_len += sizeof(reply-u.assoc_resp); +- reply-u.assoc_resp.capab_info = +- host_to_le16(hostapd_own_capab_info(hapd, sta, 0)); ++ u16 capab_info = hostapd_own_capab_info(hapd, sta, 0); ++ reply-u.assoc_resp.capab_info = host_to_le16(capab_info); + reply-u.assoc_resp.status_code = host_to_le16(status_code); +- reply-u.assoc_resp.aid = host_to_le16((sta ? sta-aid : 0) +- | BIT(14) | BIT(15)); ++ u16 aid = sta ? sta-aid : 0; ++ reply-u.assoc_resp.aid = host_to_le16(aid | BIT(14) | BIT(15)); + /* Supported rates */ + p = hostapd_eid_supp_rates(hapd, reply-u.assoc_resp.variable); + /* Extended supported rates */ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: librt should depend on libpthread, not the other way around
base-files: librt should depend on libpthread, not the other way around In uClibc 0.9.32 as well as recent versions of glibc and eglibc, librt depends on libpthread. Signed-off-by: Mark Mentovai m...@moxienet.com --- Index: package/base-files/Makefile === --- package/base-files/Makefile (revision 25547) +++ package/base-files/Makefile (working copy) @@ -196,7 +196,6 @@ define Package/libpthread $(call Package/libc/Default) TITLE:=POSIX thread library - DEPENDS:= +librt endef define Package/libpthread/config @@ -223,6 +222,7 @@ define Package/librt $(call Package/libc/Default) TITLE:=POSIX.1b RealTime extension library + DEPENDS:=+libpthread endef define Package/librt/config ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
