Re: [OpenWrt-Devel] Your confirmation is required to join the openwrt-devel mailing list

2020-04-21 Thread Lars Kruse
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


Re: [OpenWrt-Devel] confirm d2759ee7f324c3be070a8979dccb1197ab3adb41

2020-04-17 Thread Lars Kruse
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


[OpenWrt-Devel] Repository for release or snapshot build configuration?

2020-03-22 Thread Lars Kruse
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] [PATCH 4/4] scripts/gen_image_generic.sh: use /bin/sh

2019-12-29 Thread Lars Kruse
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


Re: [OpenWrt-Devel] [PATCH] x86: Add APU3 reference to x86 board.d

2018-04-22 Thread Lars Kruse
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


Re: [OpenWrt-Devel] openwrt userspace git repo location

2016-09-28 Thread Lars Kruse
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] Command to Disable Reset Button

2016-02-22 Thread Lars Kruse
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

2016-01-11 Thread Lars Kruse
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] IPTables/NAT

2015-07-11 Thread Lars Kruse
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


Re: [OpenWrt-Devel] Change Default Configuration

2015-07-07 Thread Lars Kruse
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

2015-07-07 Thread Lars Kruse
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 li...@sumpfralle.de
---
 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 EOF
+set system.$cfg='gpio_switch'
+set system.$cfg.name='$name'
+set system.$cfg.gpio_pin='$gpio_pin'
+set system.$cfg.value='$default'
+EOF
+   UCIDEF_GPIO_SWITCHES_CHANGED=1
+}
+
+ucidef_commit_gpio_switches()
+{
+   [ $UCIDEF_GPIO_SWITCHES_CHANGED = 1 ]  uci commit system
+}
+
 ucidef_set_interface_loopback() {
uci batch EOF
 set network.loopback='interface'
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
new file mode 100644
index 000..81d3982
--- /dev/null
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches
@@ -0,0 +1,25 @@
+#!/bin/sh
+#
+# Copyright (C) 2015 OpenWrt.org
+#
+
+. /lib/functions/uci-defaults.sh
+. /lib/ar71xx.sh
+
+board=$(ar71xx_board_name)
+
+case $board in
+nanostation-m)
+   ucidef_set_gpio_switch poe_passthrough PoE Passthrough 2
+   ;;
+nanostation-m-xw)
+   ucidef_set_gpio_switch poe_passthrough PoE Passthrough 8
+   ;;
+cpe510)
+   ucidef_set_gpio_switch poe_passthrough PoE Passthrough 20
+   ;;
+esac
+
+ucidef_commit_gpio_switches
+
+exit 0
-- 
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] implemented basic GPIO control

2015-06-30 Thread Lars Kruse
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 li...@sumpfralle.de
---
 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 EOF
+set system.$cfg='gpio_switch'
+set system.$cfg.name='$name'
+set system.$cfg.gpio_pin='$gpio_pin'
+set system.$cfg.value='$default'
+EOF
+   UCIDEF_GPIO_SWITCHES_CHANGED=1
+}
+
+ucidef_commit_gpio_switches()
+{
+   [ $UCIDEF_GPIO_SWITCHES_CHANGED = 1 ]  uci commit system
+}
+
 ucidef_set_interface_loopback() {
uci batch EOF
 set network.loopback='interface'
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
new file mode 100644
index 000..81d3982
--- /dev/null
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_gpio-switches
@@ -0,0 +1,25 @@
+#!/bin/sh
+#
+# Copyright (C) 2015 OpenWrt.org
+#
+
+. /lib/functions/uci-defaults.sh
+. /lib/ar71xx.sh
+
+board=$(ar71xx_board_name)
+
+case $board in
+nanostation-m)
+   ucidef_set_gpio_switch poe_passthrough PoE Passthrough 2
+   ;;
+nanostation-m-xw)
+   ucidef_set_gpio_switch poe_passthrough PoE Passthrough 8
+   ;;
+cpe510)
+   ucidef_set_gpio_switch poe_passthrough PoE Passthrough 20
+   ;;
+esac
+
+ucidef_commit_gpio_switches
+
+exit 0
-- 
2.1.4
___
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

2015-06-22 Thread Lars Kruse
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] netifd: handling of interfaces with proto none

2015-06-07 Thread Lars Kruse
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


Re: [OpenWrt-Devel] External (public) IP forwarded to internal LAN [SOLVED]

2015-05-15 Thread Lars Kruse
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


Re: [OpenWrt-Devel] External (public) IP forwarded to internal LAN

2015-05-13 Thread Lars Kruse
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] [PATCH 1/2] ar71xx: fix ethernet packet loss issues on OM5P-AN

2015-04-13 Thread Lars Kruse
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


[OpenWrt-Devel] [PATCH] [luci] Add luci support for dnsmasq option '--servers-file'

2015-03-29 Thread Lars Kruse
From: Lars Kruse de...@sumpfralle.de

Signed-off-by: Lars Kruse li...@sumpfralle.de
---
 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 abbr title=\Domain Name 
System\DNS/abbr servers.))
+
 s:taboption(advanced, Flag, strictorder,
translate(Strict order),
translate(abbr title=\Domain Name System\DNS/abbr 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] fstools / always fires 'uci commit' each reboot

2015-01-28 Thread Lars Kruse
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] [PATCH] [packages] dnsmasq: add option --quiet-dhcp

2015-01-09 Thread Lars Kruse

The --quiet-dhcp setting increases privacy by omitting DHCP lease logs
including MAC addresses.

Signed-off-by: Lars Kruse de...@sumpfralle.de

--- 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] curl: enable https protocol

2015-01-09 Thread Lars Kruse
Provide optional --enable-https flag for curl.

Signed-off-by: Lars Kruse de...@sumpfralle.de

--- 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] [PATCH] [packages] dnsmasq: add option --quiet-dhcp

2015-01-09 Thread Lars Kruse

The --quiet-dhcp setting increases privacy by omitting DHCP lease logs 
including MAC addresses.

Signed-off-by: Lars Kruse de...@sumpfralle.de

--- 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


[OpenWrt-Devel] [PATCH] base-files: led input trigger error message if kernel module is not loaded

2014-12-29 Thread Lars Kruse
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 de...@sumpfralle.de
---
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


[OpenWrt-Devel] [PATCH] curl: enable https protocol

2014-12-27 Thread Lars Kruse
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 de...@sumpfralle.de
---
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] [packages] dnsmasq: add option --quiet-dhcp

2014-12-24 Thread Lars Kruse
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 de...@sumpfralle.de
---
--- 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