Re: [OpenWrt-Devel] External (public) IP forwarded to internal LAN
Hi Angelo, > I'm facing an issue with,I think, iptables. This is the scenario: I'm > using a ddns service to point my external ip to access my server; and it > works fine, but the original address is always the internal iface of my > modem. I am not sure what is the source and the destination of your requests and where you noticed an unexpected IP (and what your expectation was). I guess that the complete firewall configuration is also necessary for analyzing this problem. Additionally the output of the following commands would be useful: iptables -L -vn iptables -t nat -L -vn (preferably in separate files) cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] External (public) IP forwarded to internal LAN
Hi Angelo, > you can find the output of the two commands on pastebin in the next 2 weeks. > > iptables -L -vn at http://pastebin.com/2b0ewSyu > iptables -t nat -L -vn at http://pastebin.com/i7qPXEMJ Here is the lan postrouting taken from the above: Chain zone_lan_postrouting (1 references) pkts bytes target prot opt in out source destination 12 860 postrouting_lan_rule all -- * * 0.0.0.0/0 0.0.0.0/0 12 860 MASQUERADEall -- * * 0.0.0.0/0 0.0.0.0/0 The last line should be the problem: every packet heading for the lan zone (e.g. your webserver) will be masqueraded (SNAT). Maybe you enabled the masquerading checkbox in the firewall config for this interface? The content of /etc/config/firewall would probably show the root cause (in case my above guess is wrong). cheers, lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] External (public) IP forwarded to internal LAN [SOLVED]
Hi Angelo, > [..] > Doest this is an error or normal behaviour of fw3 ? Could you add the network and the firewall configuration files? Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] netifd: handling of interfaces with proto "none"
Hi,
currently I am struggling with the management of dynamically created network
interfaces.
Specifically I want to create an openvpn connection to a server and add the
automatically generated network interface (tapX; managed by openvpn) to a
specific zone.
I planned to use the following commands in the up-script of my openvpn setup:
uci set "network.${netname}=interface"
uci set "network.${netname}.proto=none"
uci set "network.${netname}.ifname=$ifname"
uci add_list "firewall.@zone[1]=${netname}"
uci commit network
uci commit firewall
reload_config
But the above fails to work. Just a second after the execution of
"reload_config" the configured IP address of the openvpn client interface is
removed.
Instead I expected that the setting "proto=none" would cause this network
interface to be ignored by any network configuration code.
The high-level line of code causing the deconfiguration of the openvpn network
interface is:
ubus call network reload
I failed to analyze the netifd code in such a depth that I could tell where
the IP address is removed.
For example I tried to distribute "netifd_log_message" calls at various places
within netifd/interface.c. Sadly these log lines caused network setup
problems/lockups if placed within specific functions (e.g.
"interface_set_proto_state"). Since I used a physical device without a serial
console for testing, this debugging procedure was quite cumbersome as I had to
flash the device over and over again.
Now I am not sure how to proceed:
1) Is my assumption correct that the network interface configuration should
stay unchanged for devices with "proto=none" (luci seems to call this
setting "unmanaged")?
2) Could someone please give me a hint how to debug the network setup in order
to find the specific piece of code that manipulates network devices with the
above setting?
Cheers,
Lars
PS: the following shell commands show the effect of the deconfiguration with a
quite simple setup:
1) create a previously non-existing interface (as a vlan)
2) configure the interface
3) create a uci section for the interface with "proto=none"
4) reload the network configuration
5) one second later the previously configured IP is removed
Instead I expected it to remain unchanged.
ip addr show dev foo
ip link add link eth0 name foo type vlan id 17
ip addr show dev foo
ifconfig foo 172.16.145.1
ip addr show dev foo
uci set "network.foo=interface"
uci set "network.foo.proto=none"
uci set "network.foo.ifname=foo"
uci commit network
reload_config
ip addr show dev foo
sleep 1
ip addr show dev foo
uci delete network.foo
uci commit network
reload_config
ip link del dev foo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Controlling POE passthrough via GPIO
Hi, within our wireless community we are using a couple of devices with the following features: * powered via POE through their first ethernet plug * another device can be powered via the second ethernet plug (POE passthrough switchable via GPIO) The POE passthrough feature can be controlled via GPIO pins. For our most common devices (Nanostation M5 and TP-Link CPE510) these are GPIO pins #2, #8 or #20 (depending on the model). Currently we are using a custom script (see attached) for these models. I have the feeling that this kind of hardware capabilities should be available within openwrt (similar to the LED setup). Is there anything related already implemented within openwrt? If not: where would you recommend to put it? Cheers, Lars poe-passthrough.sh Description: application/shellscript ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] implemented basic GPIO control
Internal GPIO pins are used for PoE passthrough setups in multi-port
routers. This patch implemnets control over this hardware feature for
Ubiquiti Nanostations and TP-Link CPE510.
Signed-off-by: Lars Kruse
---
package/base-files/files/etc/init.d/gpio_switch| 42 ++
.../base-files/files/lib/functions/uci-defaults.sh | 24 +
.../base-files/etc/uci-defaults/01_gpio-switches | 25 +
3 files changed, 91 insertions(+)
create mode 100755 package/base-files/files/etc/init.d/gpio_switch
create mode 100644
target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches
diff --git a/package/base-files/files/etc/init.d/gpio_switch
b/package/base-files/files/etc/init.d/gpio_switch
new file mode 100755
index 000..1f1b44b
--- /dev/null
+++ b/package/base-files/files/etc/init.d/gpio_switch
@@ -0,0 +1,42 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2015 OpenWrt.org
+
+START=98
+STOP=10
+USE_PROCD=1
+
+
+load_gpio_switch()
+{
+ local name
+ local gpio_pin
+ local value
+
+ config_get gpio_pin "$1" gpio_pin
+ config_get name "$1" name
+ config_get value "$1" value 0
+
+ local gpio_path="/sys/class/gpio/gpio${gpio_pin}"
+ # export GPIO pin for access
+ [ -d "$gpio_path" ] || {
+ echo "$gpio_pin" >/sys/class/gpio/export
+ # we need to wait a bit until the GPIO appears
+ [ -d "$gpio_path" ] || sleep 1
+ echo out >"$gpio_path/direction"
+ }
+ # write 0 or 1 to the "value" field
+ { [ "$value" = "0" ] && echo "0" || echo "1"; } >"$gpio_path/value"
+}
+
+service_triggers()
+{
+ procd_add_reload_trigger "system"
+}
+
+start_service()
+{
+ [ -e /sys/class/gpio/ ] && {
+ config_load system
+ config_foreach load_gpio_switch gpio_switch
+ }
+}
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index 5a8809d..6577ecd 100644
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -2,6 +2,7 @@
# Copyright (C) 2011 OpenWrt.org
UCIDEF_LEDS_CHANGED=0
+UCIDEF_GPIO_SWITCHES_CHANGED=0
ucidef_set_led_netdev() {
local cfg="led_$1"
@@ -180,6 +181,29 @@ ucidef_commit_leds()
[ "$UCIDEF_LEDS_CHANGED" = "1" ] && uci commit system
}
+ucidef_set_gpio_switch() {
+ local cfg="gpio_switch_$1"
+ local name="$2"
+ local gpio_pin="$3"
+ # use "0" as default value
+ local default="${4:-0}"
+
+ uci -q get "system.$cfg" && return 0
+
+ uci batch <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change Default Configuration
Hi John, > I am able to change the settings in the file under overlay and settings > will get change, but when i do factory reset from GUI, All the changes i > have done in script file will go. I guess that the "uci-defaults" mechanism could be the right approach for you: https://wiki.openwrt.org/doc/uci#defaults cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: implemented basic GPIO control
Internal GPIO pins are used for PoE passthrough setups in multi-port
routers. This patch implemnets control over this hardware feature for
Ubiquiti Nanostations and TP-Link CPE510.
Signed-off-by: Lars Kruse
---
package/base-files/files/etc/init.d/gpio_switch| 42 ++
.../base-files/files/lib/functions/uci-defaults.sh | 24 +
.../base-files/etc/uci-defaults/01_gpio-switches | 25 +
3 files changed, 91 insertions(+)
create mode 100755 package/base-files/files/etc/init.d/gpio_switch
create mode 100644
target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches
diff --git a/package/base-files/files/etc/init.d/gpio_switch
b/package/base-files/files/etc/init.d/gpio_switch
new file mode 100755
index 000..1f1b44b
--- /dev/null
+++ b/package/base-files/files/etc/init.d/gpio_switch
@@ -0,0 +1,42 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2015 OpenWrt.org
+
+START=98
+STOP=10
+USE_PROCD=1
+
+
+load_gpio_switch()
+{
+ local name
+ local gpio_pin
+ local value
+
+ config_get gpio_pin "$1" gpio_pin
+ config_get name "$1" name
+ config_get value "$1" value 0
+
+ local gpio_path="/sys/class/gpio/gpio${gpio_pin}"
+ # export GPIO pin for access
+ [ -d "$gpio_path" ] || {
+ echo "$gpio_pin" >/sys/class/gpio/export
+ # we need to wait a bit until the GPIO appears
+ [ -d "$gpio_path" ] || sleep 1
+ echo out >"$gpio_path/direction"
+ }
+ # write 0 or 1 to the "value" field
+ { [ "$value" = "0" ] && echo "0" || echo "1"; } >"$gpio_path/value"
+}
+
+service_triggers()
+{
+ procd_add_reload_trigger "system"
+}
+
+start_service()
+{
+ [ -e /sys/class/gpio/ ] && {
+ config_load system
+ config_foreach load_gpio_switch gpio_switch
+ }
+}
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index 5a8809d..6577ecd 100644
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -2,6 +2,7 @@
# Copyright (C) 2011 OpenWrt.org
UCIDEF_LEDS_CHANGED=0
+UCIDEF_GPIO_SWITCHES_CHANGED=0
ucidef_set_led_netdev() {
local cfg="led_$1"
@@ -180,6 +181,29 @@ ucidef_commit_leds()
[ "$UCIDEF_LEDS_CHANGED" = "1" ] && uci commit system
}
+ucidef_set_gpio_switch() {
+ local cfg="gpio_switch_$1"
+ local name="$2"
+ local gpio_pin="$3"
+ # use "0" as default value
+ local default="${4:-0}"
+
+ uci -q get "system.$cfg" && return 0
+
+ uci batch <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPTables/NAT
Hi John, > I have to enable NAT with a MASQUERADING target, > and to block the GUI from WAN have to server bind only the bridge address. > Could anyone tell me how i can do it in the GUI itself. You should probably ask this kind of questions on the openwrt-users mailing list: https://lists.openwrt.org/cgi-bin/mailman/listinfo/ Anyway: You should take a look at "Administration -> Networking -> Firewall" in the web interface. There you will find everything for you task. Additional information is to be found here: http://wiki.openwrt.org/doc/uci/firewall (just read the introduction of each section - skip the long tables of options) As far as I understand you goals, everything should be configured properly by default. Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: assign proper GPIO pin for Ubiquiti Nanostation models
The GPIO pins for "POE passthrough" of Ubiquiti Nanostation models are the following: * Ubiquiti Nanostation M XM: Pin 8 * Ubiquiti Nanostation M XW: Pin 2 The previous definition of the pins was mixed up between XM and XW model. Signed-off-by: Lars Kruse --- target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches b/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches index 81d3982..b41f275 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches @@ -10,10 +10,10 @@ board=$(ar71xx_board_name) case "$board" in nanostation-m) - ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "2" + ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "8" ;; nanostation-m-xw) - ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "8" + ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "2" ;; cpe510) ucidef_set_gpio_switch "poe_passthrough" "PoE Passthrough" "20" -- 2.4.6 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Command to Disable Reset Button
Hello John, Am Sun, 21 Feb 2016 18:47:59 +0800 schrieb John kerry : > I have configured the Reset button and it's working fine for normal reset > and press for 3 seconds for factory reset. > > I need to disable the reset button using command and enable it. as far as I understand your issue, this is not a question regarding openwrt development (submitting patches and discussing them), but about its usage. Thus I would recommend to ask this on the users mailing list: https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: For sysfixtime use hwclock if RTC available
Hi, short summary for the impatient readers: the following text dives into the subtile differences between errexit (set -e) and exit status in shell scripting Am Mon, 11 Jan 2016 05:14:18 -0500 schrieb Daniel Dickinson : > I did one other test I hadn't thought of originally: > > #!/bin/sh > > set -e > > /bin/false && /bin/false > > echo "not killed" > > displays "not killed", so there still the issue that unlike if..then > with set -e, && fails to exit on error condition (for the purposes of > set -e it's like there is an implicit || /bin/true (really the exit > status just gets ignored for an AND-OR list in POSIX terms)). The dash manpage describes "-e" (errexit) as follows: The exit status of a command is considered to be explicitly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an ``&&'' or ``||'' operator. The bash manual explains the same - just a bit more lengty. Busybox's ash works in the same way, as far as I noticed. Thus the manual implies that the following two lines behave identical with regards to errexit: if [ -e /somefile ]; then action; fi [ -e /somefile ] && action In fact they do. If the test fails then action is not executed. If the test succeeds then the action is executed. The exit status of action determines the overall exit status of this line and thus may trigger errexit. The subtile difference between the above two lines is their exit status. The "if" variation returns the exit status of "action" (test succeeds) or zero (test fails). The "&&" variation returns the exit status of the last executed command. Thus a failed test returns a non-zero exit status. But due to the definition of errexit, only the exit status of the last item in a compound statement may trigger an errexit event. Thus both statements on their own will behave in the same way regarding errexit even if their exit status may differ. But there is a final catch: if these statements are the last ones in any while/for/if/case block, then their exit status determines the exit status of the whole block. Thus the surrounding while/for/if/case block may cause an errexit. Look at these examples: = example A = for a in foo bar; do [ -e "$a" ] && echo "$a" done = example B = for a in foo bar; do if [ -e "$a" ]; then echo "$a"; fi done In example (A) you will see a failure (followed by errexit) if the file "bar" does not exist. The state of "foo" is not relevant. This is a bit surprising. In example (B) there will never be an error. This is probably in line with the expectation of most users. Thus it is advisable to add a "true" statement at the end of a while/for/if/case block if last statement is a "||" or "&&" compound. This additional statement does not cover any errors. It just works around the subtile differences between "exit code" and "errexit triggering" in this specific situation. Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt userspace git repo location
Hello Valent, Am Wed, 28 Sep 2016 13:25:20 +0200 schrieb "valent.turko...@gmail.com" : > Github has become de facto standard for contributing to open source > projects, so no matter if you hate it or love it, this is just now the > new norm. > Going against the "norm" is seen by potential contributors as building > barriers for contribution. I am not sure to which part of Felix reply you are responding, but anyway ... Paul Boddie wrote a good article about using "walled gardens" in the context of Free Software (in the context of the python community): http://blogs.fsfe.org/pboddie/?p=815 For me it feels reasonable to welcome contributions through the infrastructure of an external commercial entity (github). Insisting on its solely usage sounds rather short-sighted to me. Back to the topic: Having a discussion about a suitable hosting is perfectly fine, while the decision is surely at the discretion of the maintainers (ubus: Felix?). Felix described his specific reasons why he considers the current hosting to be suitable for this piece of software. Thus I am confused that you are referring to your personal perception of the current "norm" of development instead of arguing within the scope of this specific project. Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] x86: Add APU3 reference to x86 board.d
Hi, Am Sat, 21 Apr 2018 10:17:37 +0200 schrieb Kristian Evensen : > > Are the cases stenciled with the port #’s? > > No, there are no markings on the case. just in case, that this detail is of any interest: the PCB contains labels for the three ethernet ports: http://pcengines.ch/pic/apu3a3.jpg (from: http://pcengines.ch/apu3a2.htm) Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [packages] dnsmasq: add option --quiet-dhcp
Hi,
dnsmasq supports an option "--quiet-dhcp" in order to remove DHCP log messages
from the system log. We would like to use this option in our wireless community
in order to reduce the amount of private data (MAC addresses) exposed in the
logs.
cheers,
Lars
Description:
add --quiet-dhcp option for dnsmasq (usable via "quiet_dhcp" in UCI)
This reduces the amount of private information (MAC addresses) being logged.
Signed-off-by: Lars Kruse
---
--- a/openwrt/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/openwrt/package/network/services/dnsmasq/files/dnsmasq.init
@@ -123,6 +123,7 @@ dnsmasq() {
append_bool "$cfg" nonwildcard "--bind-interfaces"
append_bool "$cfg" fqdn "--dhcp-fqdn"
append_bool "$cfg" proxydnssec "--proxy-dnssec"
+ append_bool "$cfg" quiet_dhcp "--quiet-dhcp"
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/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] curl: enable "https" protocol
Hi, even though SSL-support is configurable for curl, there is currently no support for https (just http). The attached patch fixes that. Lars Provide optional --enable-https flag for curl. Signed-off-by: Lars Kruse --- Provide optional --enable-https flag for curl. --- a/openwrt/package/network/utils/curl/Config.in +++ b/openwrt/package/network/utils/curl/Config.in @@ -53,6 +53,10 @@ config LIBCURL_HTTP bool "Enable HTTP support" default y +config LIBCURL_HTTPS + bool "Enable HTTPS support" + default n + config LIBCURL_IMAP bool "Enable IMAP support" default n --- a/openwrt/package/network/utils/curl/Makefile +++ b/openwrt/package/network/utils/curl/Makefile @@ -37,6 +37,7 @@ PKG_CONFIG_DEPENDS := \ LIBCURL_GNUTLS \ LIBCURL_GOPHER \ LIBCURL_HTTP \ + LIBCURL_HTTPS \ LIBCURL_IMAP \ LIBCURL_LDAP \ LIBCURL_LDAPS \ @@ -112,6 +113,7 @@ CONFIGURE_ARGS += \ $(if $(CONFIG_LIBCURL_GOPHER),--enable,--disable)-gopher \ $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr",--without-gnutls) \ $(if $(CONFIG_LIBCURL_HTTP),--enable,--disable)-http \ + $(if $(CONFIG_LIBCURL_HTTPS),--enable,--disable)-https \ $(if $(CONFIG_LIBCURL_IMAP),--enable,--disable)-imap \ $(if $(CONFIG_LIBCURL_LDAP),--enable,--disable)-ldap \ $(if $(CONFIG_LIBCURL_LDAPS),--enable,--disable)-ldaps \ -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: led input trigger error message if kernel module is not loaded
Hi,
I use a custom made image (for our local wifi community) with a TL-WDR4300.
Recently I disabled the config line CONFIG_PACKAGE_kmod-ledtrig-usbdev.
The absence of this module causes a bootup error message:
root@AP-1-203:/etc/rc.d# /etc/init.d/led start setting up led USB1
sh: write error: Invalid argument
/etc/rc.common: eval: line 1: can't create
/sys/class/leds/tp-link:green:usb1/device_name: nonexistent directory
/etc/rc.common: eval: line 1: can't create
/sys/class/leds/tp-link:green:usb1/activity_interval: nonexistent directory
setting up led USB2
sh: write error: Invalid argument
/etc/rc.common: eval: line 1: can't create
/sys/class/leds/tp-link:green:usb2/device_name: nonexistent directory
/etc/rc.common: eval: line 1: can't create
/sys/class/leds/tp-link:green:usb2/activity_interval: nonexistent directory
setting up led WLAN2G
After installing and loading the "ledtrig-usbdev" module the above runs fine
without error messages.
Attached you find a patch that checks the result of the trigger attempt and
emits a graceful error message with an explanation regarding the missing kernel
module instead of the rather mysterious error messages above.
Cheers,
Lars
Verify the support of the led trigger input source and complain in a helpful
way if modules are missing during bootup.
Signed-off-by: Lars Kruse
---
diff -ruN a/openwrt/package/base-files/files/etc/init.d/led
b/openwrt/package/base-files/files/etc/init.d/led
--- a/openwrt/package/base-files/files/etc/init.d/led
+++ b/openwrt/package/base-files/files/etc/init.d/led
@@ -40,7 +40,11 @@
[ $default -eq 1 ] ||
echo 0 >/sys/class/leds/${sysfs}/brightness
}
- echo $trigger > /sys/class/leds/${sysfs}/trigger
+ # this may fail if the module is not loaded
+ if ! echo $trigger > /sys/class/leds/${sysfs}/trigger
2>/dev/null; then
+ echo >&2 "Skipping trigger '$trigger' for led '$name'
due to missing kernel module"
+ return 0
+ fi
case "$trigger" in
"netdev")
[ -n "$dev" ] && {
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] dnsmasq: add option --quiet-dhcp
The --quiet-dhcp setting increases privacy by omitting DHCP lease logs
including MAC addresses.
Signed-off-by: Lars Kruse
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -123,6 +123,7 @@ dnsmasq() {
append_bool "$cfg" nonwildcard "--bind-interfaces"
append_bool "$cfg" fqdn "--dhcp-fqdn"
append_bool "$cfg" proxydnssec "--proxy-dnssec"
+ append_bool "$cfg" quiet_dhcp "--quiet-dhcp"
append_parm "$cfg" dhcpscript "--dhcp-script"
append_parm "$cfg" cachesize "--cache-size"
--
I created the above patch with quilt. Hopefully the format is suitable.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] dnsmasq: add option --quiet-dhcp
The --quiet-dhcp setting increases privacy by omitting DHCP lease logs
including MAC addresses.
Signed-off-by: Lars Kruse
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -123,6 +123,7 @@ dnsmasq() {
append_bool "$cfg" nonwildcard "--bind-interfaces"
append_bool "$cfg" fqdn "--dhcp-fqdn"
append_bool "$cfg" proxydnssec "--proxy-dnssec"
+ append_bool "$cfg" quietdhcp "--quiet-dhcp"
append_parm "$cfg" dhcpscript "--dhcp-script"
append_parm "$cfg" cachesize "--cache-size"
--
> would make sense to use 'quietdhcp' instead of 'quiet_dhcp', as the other
> options seem to ommit the dashes too.
correct - I forgot Jow's previous comment ...
Lars
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] curl: enable "https" protocol
Provide optional --enable-https flag for curl. Signed-off-by: Lars Kruse --- a/package/network/utils/curl/Config.in +++ b/package/network/utils/curl/Config.in @@ -53,6 +53,10 @@ config LIBCURL_HTTP bool "Enable HTTP support" default y +config LIBCURL_HTTPS + bool "Enable HTTPS support" + default n + config LIBCURL_IMAP bool "Enable IMAP support" default n --- a/package/network/utils/curl/Makefile +++ b/package/network/utils/curl/Makefile @@ -37,6 +37,7 @@ PKG_CONFIG_DEPENDS := \ LIBCURL_GNUTLS \ LIBCURL_GOPHER \ LIBCURL_HTTP \ + LIBCURL_HTTPS \ LIBCURL_IMAP \ LIBCURL_LDAP \ LIBCURL_LDAPS \ @@ -112,6 +113,7 @@ CONFIGURE_ARGS += \ $(if $(CONFIG_LIBCURL_GOPHER),--enable,--disable)-gopher \ $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr",--without-gnutls) \ $(if $(CONFIG_LIBCURL_HTTP),--enable,--disable)-http \ + $(if $(CONFIG_LIBCURL_HTTPS),--enable,--disable)-https \ $(if $(CONFIG_LIBCURL_IMAP),--enable,--disable)-imap \ $(if $(CONFIG_LIBCURL_LDAP),--enable,--disable)-ldap \ $(if $(CONFIG_LIBCURL_LDAPS),--enable,--disable)-ldaps \ -- Sending again with correct formatting. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] fstools / always fires 'uci commit' each reboot
Hi, > [..] > 1) > can we change that behaviour for this single script? > (delete it during first run). I guess, that script's execution should be considered successful, even if /etc/config/fstab already exists. Thus the author just failed to make sure that the exit code of that script reflects this logic. I would suggest that [ ! -f /etc/config/fstab ] && ( block detect > /etc/config/fstab ) should be changed to: [ ! -f /etc/config/fstab ] && block detect > /etc/config/fstab || true or even better (this does not hide errors in "block detect"): [ -f /etc/config/fstab ] || block detect > /etc/config/fstab (I do not see the need for the subshell here - thus I removed the brackets) This would make sure that the script exits successfully if there is the fstab file or if the "block detect" execution finished successfully. Thus the script would be deleted after its first execution (as it should be). Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] wiki.openwrt.org uses an invalid security certificate / expired on 12.2.2015 17:18
Hi, > Nope, I would vote against StartSSL. I know it is free, but the > procedure sucks, and honestly: there is *one* company on the planet > givin out *free* SSL Certs .. if that doesn't ring bells, I dunno what > could :) hehe - if they would force you to use "private" keys generated on their servers, then I would agree. But this is not the case. Thus I do not see a potential security issue. But maybe I am missing something? Personally I like their uncomplicated procedures. The only (visible) drawback is the lack of an "organization" field in the certificate - thus it does not emanate the trustful aura of a corporation. Anyway - feel free to ignore these personal opinions ... Lars pgp9ss81D6wIw.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [dnsmasq] Add option '--servers-file'
From: Lars Kruse
The option '--servers-file' is available since dnsmasq v2.69.
Signed-off-by: Lars Kruse
---
package/network/services/dnsmasq/files/dnsmasq.init | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 2e7fb7b..bca5d8f 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -152,6 +152,7 @@ dnsmasq() {
config_list_foreach "$cfg" "bogusnxdomain" append_bogusnxdomain
append_parm "$cfg" "leasefile" "--dhcp-leasefile"
append_parm "$cfg" "resolvfile" "--resolv-file"
+ append_parm "$cfg" "serversfile" "--servers-file"
append_parm "$cfg" "tftp_root" "--tftp-root"
append_parm "$cfg" "dhcp_boot" "--dhcp-boot"
append_parm "$cfg" "local_ttl" "--local-ttl"
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [luci] Add luci support for dnsmasq option '--servers-file'
From: Lars Kruse
Signed-off-by: Lars Kruse
---
modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/dhcp.lua | 5 +
1 file changed, 5 insertions(+)
diff --git
a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/dhcp.lua
b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/dhcp.lua
index 997a927..49103a8 100644
--- a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/dhcp.lua
+++ b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/dhcp.lua
@@ -89,6 +89,11 @@ s:taboption("advanced", Flag, "nonegcache",
translate("No negative cache"),
translate("Do not cache negative replies, e.g. for not existing
domains"))
+s:taboption("advanced", Value, "serversfile",
+ translate("Additional servers file"),
+ translate("This file may contain lines like 'server=/domain/1.2.3.4' or
'server=1.2.3.4' for"..
+ "domain-specific or full upstream DNS servers."))
+
s:taboption("advanced", Flag, "strictorder",
translate("Strict order"),
translate("DNS servers will
be queried in the " ..
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: fix ethernet packet loss issues on OM5P-AN
Hi, > > Observed on ubnt nanostation loco m5 xw and recent bullet m5 with phy > > having phy_id 0x004dd041 > Please post a full boot log of both affected devices. I assume that Daniel is referring to this issue: https://dev.openwrt.org/ticket/19085 I just uploaded the output of dmesg: https://dev.openwrt.org/attachment/ticket/19085/nanostation_loco_xw_boot.log Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/4] scripts/gen_image_generic.sh: use /bin/sh
Hello Rosen, Am Sun, 29 Dec 2019 19:42:51 -0800 schrieb Rosen Penev : > This has nothing bash specific. > [..] > -#!/usr/bin/env bash > +#!/bin/bash I think, the commit message indicates that you switched from bash to sh. Or did I misread it somehow? Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Repository for release or snapshot build configuration?
Hello, I am one of the developers of an OpenWrt-derived firmware (for a Freifunk community - "Opennet Initiative"). We are building images and packages for a small set of devices. But sometimes we stumble upon differences between our build setup and the one used by OpenWrt for its release (or snapshot) builds. This raises the desire to known how OpenWrt is building its release. I assume, that there is a set of build configuration snippets that are used for building the different targets. Or maybe it is combined with the buildbot setup? For now I was looking for this information in the following places: * https://openwrt.org/releases * https://openwrt.org/infrastructure * https://github.com/openwrt But for now I failed :( Any pointers are appreciated! Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] confirm d2759ee7f324c3be070a8979dccb1197ab3adb41
Am Sun, 12 Apr 2020 14:33:03 -0700 schrieb openwrt-devel-requ...@lists.openwrt.org: > Your membership in the mailing list openwrt-devel has been disabled > due to excessive bounces The last bounce received from you was dated > 12-Apr-2020. You will not get any more messages from this list until > you re-enable your membership. You will receive 3 more reminders like > this before your membership in the list is deleted. > > To re-enable your membership, you can simply respond to this message > (leaving the Subject: line intact), or visit the confirmation page at > > > http://lists.infradead.org/mailman/confirm/openwrt-devel/d2759ee7f324c3be070a8979dccb1197ab3adb41 > > > You can also visit your membership page at > > > http://lists.infradead.org/mailman/options/openwrt-devel/lists%40sumpfralle.de > > > On your membership page, you can change various delivery options such > as your email address and whether you get digests or not. As a > reminder, your membership password is > > niuwikan > > If you have any questions or problems, you can contact the list owner > at > > openwrt-devel-ow...@lists.openwrt.org ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Your confirmation is required to join the openwrt-devel mailing list
Am Tue, 21 Apr 2020 08:46:06 -0700 schrieb openwrt-devel-confirm+e8c9555ed4e7a1a44a0d3d4aa25e1aa0c66f6...@lists.openwrt.org: > Mailing list subscription confirmation notice for mailing list > openwrt-devel > > We have received a request from 185.220.101.25 for subscription of > your email address, "li...@sumpfralle.de", to the > openwrt-devel@lists.openwrt.org mailing list. To confirm that you > want to be added to this mailing list, simply reply to this message, > keeping the Subject: header intact. Or visit this web page: > > > http://lists.infradead.org/mailman/confirm/openwrt-devel/e8c9555ed4e7a1a44a0d3d4aa25e1aa0c66f618c > > > Or include the following line -- and only the following line -- in a > message to openwrt-devel-requ...@lists.openwrt.org: > > confirm e8c9555ed4e7a1a44a0d3d4aa25e1aa0c66f618c > > Note that simply sending a `reply' to this message should work from > most mail readers, since that usually leaves the Subject: line in the > right form (additional "Re:" text in the Subject: is okay). > > If you do not wish to be subscribed to this list, please simply > disregard this message. If you think you are being maliciously > subscribed to the list, or have any other questions, send them to > openwrt-devel-ow...@lists.openwrt.org. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
