[OpenWrt-Devel] [PATCH] kernel: remove DEVMEM and DEVKMEM from target's config

2018-07-02 Thread Luis Araneda 
These options are handled by generic configuration

Targets that need these options should select KERNEL_DEVMEM
and/or KERNEL_DEVKMEM options on OpenWRT's config

Signed-off-by: Luis Araneda 
---
 target/linux/at91/config-4.9 | 2 --
 target/linux/gemini/config-4.14  | 1 -
 target/linux/layerscape/armv8_32b/config-4.9 | 2 --
 target/linux/layerscape/armv8_64b/config-4.9 | 2 --
 target/linux/oxnas/config-4.14   | 1 -
 5 files changed, 8 deletions(-)

diff --git a/target/linux/at91/config-4.9 b/target/linux/at91/config-4.9
index e483d0f76d..6ccc34b957 100644
--- a/target/linux/at91/config-4.9
+++ b/target/linux/at91/config-4.9
@@ -131,8 +131,6 @@ CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
 CONFIG_DEBUG_USER=y
 CONFIG_DEFAULT_IOSCHED="noop"
 CONFIG_DEFAULT_NOOP=y
-CONFIG_DEVKMEM=y
-CONFIG_DEVMEM=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMADEVICES=y
diff --git a/target/linux/gemini/config-4.14 b/target/linux/gemini/config-4.14
index 7f093ae977..95e6b0c2c6 100644
--- a/target/linux/gemini/config-4.14
+++ b/target/linux/gemini/config-4.14
@@ -130,7 +130,6 @@ CONFIG_DECOMPRESS_XZ=y
 CONFIG_DEFAULT_CFQ=y
 # CONFIG_DEFAULT_DEADLINE is not set
 CONFIG_DEFAULT_IOSCHED="cfq"
-CONFIG_DEVMEM=y
 CONFIG_DMADEVICES=y
 CONFIG_DMATEST=y
 CONFIG_DMA_ENGINE=y
diff --git a/target/linux/layerscape/armv8_32b/config-4.9 
b/target/linux/layerscape/armv8_32b/config-4.9
index 1ee8fdb0d7..6f8ef627f7 100644
--- a/target/linux/layerscape/armv8_32b/config-4.9
+++ b/target/linux/layerscape/armv8_32b/config-4.9
@@ -297,8 +297,6 @@ CONFIG_DETECT_HUNG_TASK=y
 # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
 # CONFIG_DEVFREQ_GOV_USERSPACE is not set
 # CONFIG_DEVFREQ_THERMAL is not set
-CONFIG_DEVKMEM=y
-CONFIG_DEVMEM=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMADEVICES=y
diff --git a/target/linux/layerscape/armv8_64b/config-4.9 
b/target/linux/layerscape/armv8_64b/config-4.9
index c4c325acfb..0873b2a8c1 100644
--- a/target/linux/layerscape/armv8_64b/config-4.9
+++ b/target/linux/layerscape/armv8_64b/config-4.9
@@ -322,8 +322,6 @@ CONFIG_DEFAULT_CFQ=y
 CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
 CONFIG_DEFAULT_IOSCHED="cfq"
 CONFIG_DETECT_HUNG_TASK=y
-CONFIG_DEVKMEM=y
-CONFIG_DEVMEM=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_DEV_DAX is not set
diff --git a/target/linux/oxnas/config-4.14 b/target/linux/oxnas/config-4.14
index 4d6943aea5..1bf7d0c072 100644
--- a/target/linux/oxnas/config-4.14
+++ b/target/linux/oxnas/config-4.14
@@ -103,7 +103,6 @@ CONFIG_DECOMPRESS_XZ=y
 CONFIG_DEFAULT_CFQ=y
 # CONFIG_DEFAULT_DEADLINE is not set
 CONFIG_DEFAULT_IOSCHED="cfq"
-CONFIG_DEVMEM=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMA_CMA=y
-- 
2.18.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] firewall3: make reject types selectable by user

2018-07-02 Thread Alin Nastac 
From: Alin Nastac 

RFC 6092 recommends in section 3.3.1 that an IPv6 CPE must respond to
unsolicited inbound SYNs with an ICMPv6 Destination Unreachable error
code 1 (Communication with destination administratively prohibited).

Signed-off-by: Alin Nastac 
---
 defaults.c | 21 -
 options.h  |  2 ++
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/defaults.c b/defaults.c
index 11fbf0d..6565ca2 100644
--- a/defaults.c
+++ b/defaults.c
@@ -41,6 +41,8 @@ const struct fw3_option fw3_flag_opts[] = {
FW3_OPT("output",  target,   defaults, policy_output),
 
FW3_OPT("drop_invalid",bool, defaults, drop_invalid),
+   FW3_OPT("tcp_reset_rejects",   bool, defaults, tcp_reset_rejects),
+   FW3_OPT("admin_prohib_rejects",bool, defaults, 
admin_prohib_rejects),
 
FW3_OPT("syn_flood",   bool, defaults, syn_flood),
FW3_OPT("synflood_protect",bool, defaults, syn_flood),
@@ -113,6 +115,7 @@ fw3_load_defaults(struct fw3_state *state, struct 
uci_package *p)
 
defs->syn_flood_rate.rate  = 25;
defs->syn_flood_rate.burst = 50;
+   defs->tcp_reset_rejects= true;
defs->tcp_syncookies   = true;
defs->tcp_window_scaling   = true;
defs->custom_chains= true;
@@ -276,14 +279,22 @@ fw3_print_default_head_rules(struct fw3_ipt_handle 
*handle,
fw3_ipt_rule_append(r, "INPUT");
}
 
-   r = fw3_ipt_rule_create(handle, , NULL, NULL, NULL, NULL);
-   fw3_ipt_rule_target(r, "REJECT");
-   fw3_ipt_rule_addarg(r, false, "--reject-with", "tcp-reset");
-   fw3_ipt_rule_append(r, "reject");
+   if (defs->tcp_reset_rejects)
+   {
+   r = fw3_ipt_rule_create(handle, , NULL, NULL, NULL, 
NULL);
+   fw3_ipt_rule_target(r, "REJECT");
+   fw3_ipt_rule_addarg(r, false, "--reject-with", 
"tcp-reset");
+   fw3_ipt_rule_append(r, "reject");
+   }
 
r = fw3_ipt_rule_new(handle);
fw3_ipt_rule_target(r, "REJECT");
-   fw3_ipt_rule_addarg(r, false, "--reject-with", "port-unreach");
+   fw3_ipt_rule_addarg(r, false, "--reject-with",
+   defs->admin_prohib_rejects ?
+   (handle->family == FW3_FAMILY_V6 ?
+   "adm-prohibited" :
+   "admin-prohib") :
+   "port-unreach");
fw3_ipt_rule_append(r, "reject");
 
break;
diff --git a/options.h b/options.h
index 08fecf6..e3ba99c 100644
--- a/options.h
+++ b/options.h
@@ -276,6 +276,8 @@ struct fw3_defaults
enum fw3_flag policy_forward;
 
bool drop_invalid;
+   bool tcp_reset_rejects;
+   bool admin_prohib_rejects;
 
bool syn_flood;
struct fw3_limit syn_flood_rate;
-- 
2.7.4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] turris onmia - broken uboot-env

2018-07-02 Thread Mirko Langisch 
On Mon, 02 Jul 2018, Sven Roederer wrote:

> it's a bit off-topic, but probably someone can share the correct uboot-env of 
> a Turris-Omnia 2G.
> Mine is not bootingafter somehow damaging the settings.
> 
> A simple printenv would be great.

does 

env default -a
saveenv

help?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] turris onmia - broken uboot-env

2018-07-02 Thread Sven Roederer 
Hi,

it's a bit off-topic, but probably someone can share the correct uboot-env of 
a Turris-Omnia 2G.
Mine is not bootingafter somehow damaging the settings.

A simple printenv would be great.


Thanks Sven

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] services/uhttpd: add -M option for Last-Modified header sending

2018-07-02 Thread Florian Eckert 
If uhttpd is started with the option -M then Last-Modified header is not
send during ok respond. We have already an ETag header set which is more
accurate.

See URL:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Etag

So make sending of Last-Modified header optional with a config option.
If the option is not set then the behaviour is as before this option was
added.

Signed-off-by: Florian Eckert 
---
 ...ct-if-last-modified-header-should-be-send.patch | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 
package/network/services/uhttpd/patches/0001-add-a-M-option-to-select-if-last-modified-header-should-be-send.patch

diff --git 
a/package/network/services/uhttpd/patches/0001-add-a-M-option-to-select-if-last-modified-header-should-be-send.patch
 
b/package/network/services/uhttpd/patches/0001-add-a-M-option-to-select-if-last-modified-header-should-be-send.patch
new file mode 100644
index 00..9835ca8cfd
--- /dev/null
+++ 
b/package/network/services/uhttpd/patches/0001-add-a-M-option-to-select-if-last-modified-header-should-be-send.patch
@@ -0,0 +1,46 @@
+--- a/file.c
 b/file.c
+@@ -337,8 +337,9 @@ static void uh_file_response_ok_hdrs(str
+ 
+   if (s) {
+   ustream_printf(cl->us, "ETag: %s\r\n", uh_file_mktag(s, buf, 
sizeof(buf)));
+-  ustream_printf(cl->us, "Last-Modified: %s\r\n",
+- uh_file_unix2date(s->st_mtime, buf, 
sizeof(buf)));
++  if(!conf.no_last_modified_header)
++  ustream_printf(cl->us, "Last-Modified: %s\r\n",
++ uh_file_unix2date(s->st_mtime, buf, 
sizeof(buf)));
+   }
+   ustream_printf(cl->us, "Date: %s\r\n",
+  uh_file_unix2date(time(NULL), buf, sizeof(buf)));
+--- a/main.c
 b/main.c
+@@ -232,7 +232,7 @@ int main(int argc, char **argv)
+   init_defaults_pre();
+   signal(SIGPIPE, SIG_IGN);
+ 
+-  while ((ch = getopt(argc, argv, 
"A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
++  while ((ch = getopt(argc, argv, 
"A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:Mm:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
+   switch(ch) {
+ #ifdef HAVE_TLS
+   case 'C':
+@@ -311,6 +311,10 @@ int main(int argc, char **argv)
+   conf.rfc1918_filter = 1;
+   break;
+ 
++  case 'M':
++  conf.no_last_modified_header = 1;
++  break;
++
+   case 'n':
+   conf.max_script_requests = atoi(optarg);
+   break;
+--- a/uhttpd.h
 b/uhttpd.h
+@@ -77,6 +77,7 @@ struct config {
+   int ubus_noauth;
+   int ubus_cors;
+   int cgi_prefix_len;
++  int no_last_modified_header;
+   struct list_head cgi_alias;
+ };
+ 
-- 
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] services/uhttpd: Disable option -M for Last-Modified header

2018-07-02 Thread Florian Eckert 
Make Last-Modified header configurable over uci.
If option is not set then send Last-Modified header.
This is the equal to the behaviour as before this option was added.

Signed-off-by: Florian Eckert 
---
 package/network/services/uhttpd/files/uhttpd.init | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/services/uhttpd/files/uhttpd.init 
b/package/network/services/uhttpd/files/uhttpd.init
index 47270bcc15..2367ac137f 100755
--- a/package/network/services/uhttpd/files/uhttpd.init
+++ b/package/network/services/uhttpd/files/uhttpd.init
@@ -127,6 +127,7 @@ start_instance()
append_bool "$cfg" no_symlinks "-S" 0
append_bool "$cfg" no_dirlists "-D" 0
append_bool "$cfg" rfc1918_filter "-R" 0
+   append_bool "$cfg" no_last_modified_header "-M" 0
 
config_get alias_list "$cfg" alias
for alias in $alias_list; do
-- 
2.11.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MR24 sysupgrade seems to be broken

2018-07-02 Thread Christian Lamparter 
On Sunday, July 1, 2018 2:26:35 AM CEST Russell Senior wrote:
> Here is what shows during sysupgrade:
> 
> https://pastebin.com/YfbQZ5fB
>
Have you tried the aforementioned fix for the buggy mtd-utils on
your old/existing installation or not?

> On Sat, Jun 30, 2018 at 6:49 AM, Christian Lamparter 
> wrote:
> > On Saturday, June 30, 2018 10:06:21 AM CEST Russell Senior wrote:
> > > I just tried updating a Meraki MR24 to current master, from an image a
> > few
> > > months old and it broke.  I get a new kernel, but an old rootfs.  I have
> > > some of these deployed where a serial connection is awkward.  It would be
> > > nice if sysupgrade worked.
> > >
> > Any idea what broke it? From your description "new kernel, old rootfs" it
> > could be the mtd-utils update to 2.0.2 that broke it:
> >
> >  > f37f63f38ccb706b196fe4934d0d9d92537eb832>
> >
> > and this was fixed by me just this month:
> >
> >  > daf19649dbf101ce7ae17abf84eeed7a30b41275>
> > (also upstream  > 0f833ac73ad631248826386e2918d8571ecf0347>)
> >
> > so I think you would need to somehow update the mtd-utils
> > package (ubinfo, ubimkvol, ubirmvol, ...)  on your old routers
> > before performing sysupgrading in order to fix this.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] arc: Update variables substitutions in u-boot env files

2018-07-02 Thread Evgeniy Didin 
From: Evgeniy Didin 

In the latest version of u-boot (2018.05) there was a swith to 
Hush shell for ARC AXS10x boards(arc770/archs38):
commit 9249d74781e1 ("ARC: AXS10x: Enable hush shell").
In Hush shell using "$()" to declare envitonment variables is forbidden,
instead of this "${}" need to be used.

---
 target/linux/arc770/image/uEnv.txt  | 6 +++---
 target/linux/archs38/image/uEnv.txt | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/target/linux/arc770/image/uEnv.txt 
b/target/linux/arc770/image/uEnv.txt
index 35549cb1c4..53632e8bb6 100644
--- a/target/linux/arc770/image/uEnv.txt
+++ b/target/linux/arc770/image/uEnv.txt
@@ -1,7 +1,7 @@
 setenv kernel_addr_r 0x8200
 setenv fdt_addr_r 0x8300
-setenv loadkernel fatload mmc 0 \$(kernel_addr_r) uImage
-setenv loaddtb fatload mmc 0 \$(fdt_addr_r) \$(dts)
+setenv loadkernel fatload mmc 0 \${kernel_addr_r} uImage
+setenv loaddtb fatload mmc 0 \${fdt_addr_r} \${dts}
 setenv bootargs earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=ttyS3,115200n8 root=/dev/mmcblk0p2 rootwait print-fatal-signals=1
-setenv uenvcmd run loadkernel\; run loaddtb\; bootm \$(kernel_addr_r) - 
\$(fdt_addr_r)
+setenv uenvcmd run loadkernel\; run loaddtb\; bootm \${kernel_addr_r} - 
\${fdt_addr_r}
 run uenvcmd
diff --git a/target/linux/archs38/image/uEnv.txt 
b/target/linux/archs38/image/uEnv.txt
index 35549cb1c4..53632e8bb6 100644
--- a/target/linux/archs38/image/uEnv.txt
+++ b/target/linux/archs38/image/uEnv.txt
@@ -1,7 +1,7 @@
 setenv kernel_addr_r 0x8200
 setenv fdt_addr_r 0x8300
-setenv loadkernel fatload mmc 0 \$(kernel_addr_r) uImage
-setenv loaddtb fatload mmc 0 \$(fdt_addr_r) \$(dts)
+setenv loadkernel fatload mmc 0 \${kernel_addr_r} uImage
+setenv loaddtb fatload mmc 0 \${fdt_addr_r} \${dts}
 setenv bootargs earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=ttyS3,115200n8 root=/dev/mmcblk0p2 rootwait print-fatal-signals=1
-setenv uenvcmd run loadkernel\; run loaddtb\; bootm \$(kernel_addr_r) - 
\$(fdt_addr_r)
+setenv uenvcmd run loadkernel\; run loaddtb\; bootm \${kernel_addr_r} - 
\${fdt_addr_r}
 run uenvcmd
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ath9k: Expose support for Dynack

2018-07-02 Thread Koen Vandeputte 
Enables support for Dynack feature.

When a remote station is far away, we need to compensate for the distance
by allowing more time for an ACK to arrive back before issueing a 
retransmission.
Currently, it needs to be set fixed to indicate the maximum distance the remote
station will ever be.

While this mostly works for static antennae, it introduces 2 issues:
- If the actual distance is less, speed is reduced due to a lot of wates 
wait-time
- If the distance becomes greater, retries start to occur and comms can get 
lost.

Allowing to set it dynamically using dynack ensures the best possible tradeoff
between speed vs distance.

This feature is currently only supported in ath9k.
it is also disabled by default.

Enabling it can be done in 2 ways:
- issue cmd:  iw phy0 set distance auto
- sending the NL80211_ATTR_WIPHY_DYN_ACK flag to mac80211 driver using netlink

Disabling it can be done by providing a valid fixed value.

To give an idea of a practical example:

In my usecase, we have mesh wifi device installed on ships/platforms.
Currently, the coverage class is set at 12000m fixed.

When a vessel moved closer (ex. 1500m), the measured link capacity was a lot
lower compared to setting the coverage class fixed to 1500m

Dynack completely solved this, nearly providing double the bandwidth at closer 
range
compared to the fixed setting of 12000m being used.

Also when a vessel sailed to a distance greater than the fixed setting,
communication was lost as the ACK's never arrived within the max allowed 
timeframe.

Actual distance: 6010m
iperf 60s run avg

Fixed 12150m:  31 Mbit/s
Dynack:58 Mbit/s

Fixed 6300m:   51 Mbit/s
Dynack:59 Mbit/s

Fixed 3000m:   13 Mbit/s  (lots of retries)
Dynack:58 Mbit/s

Actual distance: 1504m
iperf 60s run avg

Fixed 12150m:  31 Mbit/s
Dynack:86 Mbit/s

Fixed 6300m:   55 Mbit/s
Dynack:87 Mbit/s

Fixed 3000m:   67 Mbit/s
Dynack:87 Mbit/s

Signed-off-by: Koen Vandeputte 
---
 package/kernel/mac80211/Makefile | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 3c88e451f1e2..611d5a73d89b 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -57,6 +57,7 @@ PKG_CONFIG_DEPENDS:= \
CONFIG_PACKAGE_ATH_DEBUG \
CONFIG_PACKAGE_ATH_DFS \
CONFIG_PACKAGE_ATH_SPECTRAL \
+   CONFIG_PACKAGE_ATH_DYNACK \
CONFIG_PACKAGE_B43_DEBUG \
CONFIG_PACKAGE_B43_PIO \
CONFIG_PACKAGE_B43_PHY_G \
@@ -199,6 +200,17 @@ define KernelPackage/ath/config
help
  Say Y to enable access to the FFT/spectral data via debugfs.
 
+   config PACKAGE_ATH_DYNACK
+   bool "Enable Dynack support"
+   depends on PACKAGE_kmod-ath9k-common
+   help
+ Enables support for Dynamic ACK estimation, which allows the 
fastest possible speed
+ at any distance automatically by increasing/decreasing the 
max frame ACK time for
+ the most remote station detected.  It can be enabled by using 
iw (iw phy0 set distance auto),
+ or by sending the NL80211_ATTR_WIPHY_DYN_ACK flag to mac80211 
driver using netlink.
+
+ Select this option if you want to enable this feature
+
   endif
 endef
 
@@ -1630,7 +1642,7 @@ config-$(call config_package,ath) += ATH_CARDS ATH_COMMON 
ATH_REG_DYNAMIC_USER_R
 config-$(CONFIG_PACKAGE_ATH_DEBUG) += ATH_DEBUG ATH10K_DEBUG 
ATH9K_STATION_STATISTICS
 config-$(CONFIG_PACKAGE_ATH_DFS) += ATH9K_DFS_CERTIFIED ATH10K_DFS_CERTIFIED
 config-$(CONFIG_PACKAGE_ATH_SPECTRAL) += ATH9K_COMMON_SPECTRAL ATH10K_SPECTRAL
-
+config-$(CONFIG_PACKAGE_ATH_DYNACK) += ATH9K_DYNACK
 config-$(call config_package,ath9k) += ATH9K
 config-$(call config_package,ath9k-common) += ATH9K_COMMON
 config-$(CONFIG_TARGET_ar71xx) += ATH9K_AHB
-- 
2.7.4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hostapd: announce utf8 encoding of ssid

2018-07-02 Thread Jouke Witteveen 
On Mon, Jul 2, 2018 at 6:58 AM John Crispin  wrote:
>
>
>
> On 28/06/18 22:47, Jouke Witteveen wrote:
> > + set_default utf8_ssid 1
>
> does this not make it use utf8 by default ?

Yes, it does. I argued that it is utf8 anyway, unless we do some
manual tinkering. An SSID set via LuCI is almost guaranteed to be utf8
an encoded string.

In the end, setting the bit or not should me more or less
inconsequential. It is only there to tell the client how to display
the SSID. Most clients seem to assume utf8 encoding anyway, but it
would be good practice to use this bit. Without the bit, the SSID
should really be treated as a meaningless (non human-readable) byte
string.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel