Re: [OpenWrt-Devel] Removing Telnet

[Steven Barth]

Hello Michael,

that is interesting, though I guess since these are mainly our default
it shouldn't be too hard for someone manufacturing to change the config
and readd a simple init-script for telnetd if that is really required.

Lack of entropy doesn't seem to be too much of an issue here, in fact
in failsafe mode we generate a 1024 bit RSA-key on demand which takes
<2s on my old Buffalo here. Granted its only 1024-bit but still. Now
the regular keys are 2048-bit which takes about a minute which could
be seen as problematic.

However in the verge of making these changes we also removed DSS support
and removed some of the ciphers (3DES, Twofish) and CBC mode in general
as well, so we at least save ourselves the DSS key generation.

In the future we might want to switch to add ed25519 since its more secure
and probably faster than the classical approaches mechanisms here, but we
have to ensure that it is compatible with at least most common SSH clients
out there, mainly probably Putty on Windows and OpenSSH on Linux & OS X.


Cheers,

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

[OpenWrt-Devel] [PATCH v2 1/8] ar71xx: add kernel support for the OpenMesh MR1750 board

[Sven Eckelmann]

Signed-off-by: Sven Eckelmann 
---
v2:
 - rebased on top of r46832

 target/linux/ar71xx/config-4.1 |   1 +
 .../ar71xx/files/arch/mips/ath79/mach-mr1750.c | 129 +
 .../815-MIPS-ath79-add-mr1750-support.patch|  39 +++
 3 files changed, 169 insertions(+)
 create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
 create mode 100644 
target/linux/ar71xx/patches-4.1/815-MIPS-ath79-add-mr1750-support.patch

diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
index 21c4601..5188f6b 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -81,6 +81,7 @@ CONFIG_ATH79_MACH_JWAP003=y
 CONFIG_ATH79_MACH_MC_MAC1200R=y
 CONFIG_ATH79_MACH_MR12=y
 CONFIG_ATH79_MACH_MR16=y
+CONFIG_ATH79_MACH_MR1750=y
 CONFIG_ATH79_MACH_MR600=y
 CONFIG_ATH79_MACH_MR900=y
 CONFIG_ATH79_MACH_MYNET_N600=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
new file mode 100644
index 000..8ace02f
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr1750.c
@@ -0,0 +1,129 @@
+/*
+ * MR1750 board support
+ *
+ * Copyright (c) 2012 Qualcomm Atheros
+ * Copyright (c) 2012-2013 Marek Lindner 
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "dev-ap9x-pci.h"
+#include "dev-gpio-buttons.h"
+#include "dev-eth.h"
+#include "dev-leds-gpio.h"
+#include "dev-m25p80.h"
+#include "dev-wmac.h"
+#include "machtypes.h"
+#include "pci.h"
+
+#define MR1750_GPIO_LED_LAN12
+#define MR1750_GPIO_LED_WLAN_2G13
+#define MR1750_GPIO_LED_STATUS_GREEN   19
+#define MR1750_GPIO_LED_STATUS_RED 21
+#define MR1750_GPIO_LED_POWER  22
+#define MR1750_GPIO_LED_WLAN_5G23
+
+#define MR1750_GPIO_BTN_RESET  17
+
+#define MR1750_KEYS_POLL_INTERVAL  20  /* msecs */
+#define MR1750_KEYS_DEBOUNCE_INTERVAL  (3 * MR1750_KEYS_POLL_INTERVAL)
+
+#define MR1750_MAC0_OFFSET 0
+#define MR1750_WMAC_CALDATA_OFFSET 0x1000
+
+static struct gpio_led mr1750_leds_gpio[] __initdata = {
+   {
+   .name   = "mr1750:blue:power",
+   .gpio   = MR1750_GPIO_LED_POWER,
+   .active_low = 1,
+   },
+   {
+   .name   = "mr1750:blue:wan",
+   .gpio   = MR1750_GPIO_LED_LAN,
+   .active_low = 1,
+   },
+   {
+   .name   = "mr1750:blue:wlan24",
+   .gpio   = MR1750_GPIO_LED_WLAN_2G,
+   .active_low = 1,
+   },
+   {
+   .name   = "mr1750:blue:wlan58",
+   .gpio   = MR1750_GPIO_LED_WLAN_5G,
+   .active_low = 1,
+   },
+   {
+   .name   = "mr1750:green:status",
+   .gpio   = MR1750_GPIO_LED_STATUS_GREEN,
+   .active_low = 1,
+   },
+   {
+   .name   = "mr1750:red:status",
+   .gpio   = MR1750_GPIO_LED_STATUS_RED,
+   .active_low = 1,
+   },
+};
+
+static struct gpio_keys_button mr1750_gpio_keys[] __initdata = {
+   {
+   .desc   = "Reset button",
+   .type   = EV_KEY,
+   .code   = KEY_RESTART,
+   .debounce_interval = MR1750_KEYS_DEBOUNCE_INTERVAL,
+   .gpio   = MR1750_GPIO_BTN_RESET,
+   .active_low = 1,
+   },
+};
+
+static void __init mr1750_setup(void)
+{
+   u8 *art = (u8 *)KSEG1ADDR(0x1fff);
+   u8 mac[6];
+
+   ath79_eth0_pll_data.pll_1000 = 0xbe000101;
+   ath79_eth0_pll_data.pll_100 = 0x8101;
+   ath79_eth0_pll_data.pll_10 = 0x80001313;
+
+   ath79_register_m25p80(NULL);
+
+   ath79_register_leds_gpio(-1, ARRAY_SIZE(mr1750_leds_gpio),
+mr1750_leds_gpio);
+   ath79_register_gpio_keys_polled(-1, MR1750_KEYS_POLL_INTERVAL,
+   ARRAY_SIZE(mr1750_gpio_keys),
+   

[OpenWrt-Devel] [PATCH v2 2/8] ar71xx: add user-space support for the OpenMesh MR1750 board

[Sven Eckelmann]

Signed-off-by: Sven Eckelmann 
---
v2:
 - rebased on top of r46832

 target/linux/ar71xx/base-files/etc/diag.sh | 3 +++
 target/linux/ar71xx/base-files/etc/uci-defaults/01_leds| 6 ++
 target/linux/ar71xx/base-files/etc/uci-defaults/02_network | 1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   | 3 +++
 4 files changed, 13 insertions(+)

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 36de775..68eac50 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -147,6 +147,9 @@ get_status_led() {
mr600v2)
status_led="mr600:blue:power"
;;
+   mr1750)
+   status_led="mr1750:blue:power"
+   ;;
mr900 | \
mr900v2)
status_led="mr900:blue:power"
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index e7f7a4c..b701570 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -257,6 +257,12 @@ mr600)
ucidef_set_led_wlan "wlan58" "WLAN58" "mr600:green:wlan58" "phy0tpt"
;;
 
+mr1750)
+   ucidef_set_led_netdev "lan" "LAN" "mr1750:blue:wan" "eth0"
+   ucidef_set_led_wlan "wlan58" "WLAN58" "mr1750:blue:wlan58" "phy0tpt"
+   ucidef_set_led_wlan "wlan24" "WLAN24" "mr1750:blue:wlan24" "phy1tpt"
+   ;;
+
 mr900 | \
 mr900v2)
ucidef_set_led_netdev "lan" "LAN" "mr900:blue:wan" "eth0"
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 686fce9..d9053be 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -338,6 +338,7 @@ eap300v2 |\
 eap7660d |\
 el-mini |\
 loco-m-xw |\
+mr1750 |\
 mr600 |\
 mr600v2 |\
 mr900 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index e1f345e..d2bf0ae 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -511,6 +511,9 @@ ar71xx_board_detect() {
*MR600v2)
name="mr600v2"
;;
+   *MR1750)
+   name="mr1750"
+   ;;
*MR600)
name="mr600"
;;
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] uqmi: Add proper IPv6 support

[Steven Barth]

Hello Matti,

thanks, I very much support this patch.
One little thing:

proto_add_ipv6_route "::0" 0 "$gateway_6"

should be

proto_add_ipv6_route "::0" 0 "$gateway_6" "" "" "${ip_6}/${ip_prefix_length}"

otherwise this might break IPv6 connectivity in the presence of other
IPv6 connections. In general for IPv6 routes must be source-restricted
to the prefixes and addresses that the ISP delegated, otherwise it might
happen that the routers tries to route traffic with source-addresses
from a different ISP through this connection and the ISP might drop the traffic
due to the source-addressing being "spoofed" essentially creating a blackhole.



Cheers,

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

Re: [OpenWrt-Devel] Removing Telnet

[Hannu Nyman]

Steven Barth wrote at Wed Sep 9 08:10:18 CEST 2015:
> Lack of entropy doesn't seem to be too much of an issue here, in fact in 
failsafe mode we generate a 1024 bit RSA-key on demand which takes <2s on my 
old Buffalo here. Granted its only 1024-bit but still. Now the regular keys 
are 2048-bit which takes about a minute which could be seen as problematic.


That time seems to vary by router. I tested yesterday with my ar71xx/WNDR3700 
r46803:
removing the RSA-key before reboot (and thus forcing the dropbear init script 
to generate a new key before launching the actual dropbear process) will 
delay the launch of the dropbear process by some 15 seconds. That can be 
easily seen from the system log by comparing the timestamps and the position 
of dropbear startup message in the log. The 15 second delay was consistent on 
several reboots with r46803.


Running the dropbear key generation manually from console takes only 2-3 
seconds, but then the router is already fully up and has generated more entropy.



Interestingly, right now with r46832, the recent ip/ifconfig changes have 
apparently caused some additional lag to the key generation in a normal boot, 
as the dropbear startup delay with key generation is now 39 seconds. Below 
are two log excerpts showing the impact.
* If RSA key exists, the dropbear startup is consistently at the same place 
right after mtdblock handling.
* If the key needs to be generated, dropbear starts 39 secs later. (log shows 
the sysfixtime clock jump for clarity)


I briefly tested the failsafe mode, and there dropbear ssh seems to be 
reachable some 15-20 seconds after the failsafe mode has been selected (led 
blinks rapidly). That is consistent with the yesterday's observations about 
the key generation at startup.


Reboot, normal, RSA key exists
=
Tue Sep  8 22:40:01 2015 kern.info kernel: [   18.152072] ieee80211 phy1: 
Atheros AR9280 Rev:2 mem=0xb001, irq=41
Tue Sep  8 22:40:03 2015 user.emerg : this file has been obsoleted. please 
call "/sbin/block mount" directly
Tue Sep  8 22:40:04 2015 daemon.err block: mounting /dev/mtdblock4 (squashfs) 
as /mnt/mtdblock4 failed (-1) - No error information

Tue Sep  8 22:40:04 2015 daemon.err block: /dev/mtdblock5 is already mounted
Tue Sep  8 22:40:05 2015 authpriv.warn dropbear[1251]: Failed loading 
/etc/dropbear/dropbear_ecdsa_host_key

Tue Sep  8 22:40:05 2015 authpriv.info dropbear[1251]: Not backgrounding
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_multiport

Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_comment
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - xt_length
Tue Sep  8 22:40:07 2015 daemon.err insmod: module is already loaded - 
xt_multiport
Tue Sep  8 22:40:07 2015 kern.debug kernel: [   26.527131] ar71xx: pll_reg 
0xb8050010: 0x



Reboot, RSA key deleted before reboot
=
Tue Sep  8 22:40:04 2015 daemon.err block: mounting /dev/mtdblock4 (squashfs) 
as /mnt/mtdblock4 failed (-1) - No error information

Tue Sep  8 22:40:04 2015 daemon.err block: /dev/mtdblock5 is already mounted
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_multiport

Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - 
xt_comment
Tue Sep  8 22:40:06 2015 daemon.err insmod: module is already loaded - xt_length
...
Tue Sep  8 22:40:36 2015 user.notice SQM: cur_target: auto cur_bandwidth: 1
Wed Sep  9 10:57:12 2015 user.notice SQM: get_target defaulting to auto.
...
Wed Sep  9 10:57:21 2015 authpriv.warn dropbear[3625]: Failed loading 
/etc/dropbear/dropbear_ecdsa_host_key

Wed Sep  9 10:57:21 2015 authpriv.info dropbear[3625]: Not backgrounding
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 6/8] package/uboot-envtools: add OpenMesh MR1750 support

[Sven Eckelmann]

Signed-off-by: Sven Eckelmann 
---
v2:
 - rebased on top of r46832

 package/boot/uboot-envtools/files/ar71xx | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/boot/uboot-envtools/files/ar71xx 
b/package/boot/uboot-envtools/files/ar71xx
index 8fb559e..0c81f328 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -20,6 +20,7 @@ carambola2 | \
 eap300v2 | \
 hornet-ub | \
 hornet-ub-x2 | \
+mr1750 | \
 mr600 | \
 mr600v2 | \
 mr900 | \
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/4] Search for libjson along with libjson-c

[Bachtin, Dmitri]

Signed-off-by: Dmitri Bachtin 
---
 CMakeLists.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 65819c3..ecb1508 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -9,7 +9,7 @@ OPTION(BUILD_LUA "build Lua plugin" ON)
 OPTION(BUILD_EXAMPLES "build examples" ON)
 
 INCLUDE(FindPkgConfig)
-PKG_SEARCH_MODULE(JSONC json-c)
+PKG_SEARCH_MODULE(JSONC json-c json)
 IF(JSONC_FOUND)
   ADD_DEFINITIONS(-DJSONC)
   INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
@@ -42,7 +42,7 @@ INSTALL(TARGETS ubox ubox-static
 ADD_SUBDIRECTORY(lua)
 ADD_SUBDIRECTORY(examples)
 
-find_library(json NAMES json-c)
+find_library(json NAMES json-c json)
 IF(EXISTS ${json})
ADD_LIBRARY(blobmsg_json SHARED blobmsg_json.c)
TARGET_LINK_LIBRARIES(blobmsg_json ubox ${json})
-- 
1.7.2.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/4] b64_encode(): fixed input[] not initialized warn under gcc 4.4.5

[Bachtin, Dmitri]

Signed-off-by: Dmitri Bachtin 
---
 base64.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/base64.c b/base64.c
index b6f8bf3..4186ce8 100644
--- a/base64.c
+++ b/base64.c
@@ -140,7 +140,7 @@ int b64_encode(const void *_src, size_t srclength,
const unsigned char *src = _src;
char *target = dest;
size_t datalength = 0;
-   u_char input[3];
+   u_char input[3] = {0};
u_char output[4];
int i;
 
-- 
1.7.2.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/4] blobmsg_add_json_from_file(): fixed const-correctness with libjson

[Bachtin, Dmitri]

libjson's json_object_from_file takes a non-const char buffer as
its second parameter while libjson-c takes a const one. Use
strdup() to avoid using const data as non-const.

Signed-off-by: Dmitri Bachtin 
---
 blobmsg_json.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/blobmsg_json.c b/blobmsg_json.c
index ffde23d..de876cf 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -97,7 +97,10 @@ out:
 
 bool blobmsg_add_json_from_file(struct blob_buf *b, const char *file)
 {
-   return __blobmsg_add_json(b, json_object_from_file(file));
+   char* __file = strdup(file);
+   bool result = __blobmsg_add_json(b, json_object_from_file(__file));
+   free(__file);
+   return result;
 }
 
 bool blobmsg_add_json_from_string(struct blob_buf *b, const char *str)
-- 
1.7.2.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 3/8] scripts/om-fwupgradecfg-gen.sh: add support for the MR1750

[Sven Eckelmann]

Signed-off-by: Sven Eckelmann 
---
v2:
 - rebased on top of r46832

 scripts/om-fwupgradecfg-gen.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/om-fwupgradecfg-gen.sh b/scripts/om-fwupgradecfg-gen.sh
index d385e5e..fab1582 100644
--- a/scripts/om-fwupgradecfg-gen.sh
+++ b/scripts/om-fwupgradecfg-gen.sh
@@ -7,7 +7,7 @@
 #
 
 usage() {
-   echo "Usage: $0    
"
+   echo "Usage: $0    "
rm -f $CFG_OUT
exit 1
 }
@@ -26,7 +26,7 @@ case $CE_TYPE in
FLASH_BS=262144
MD5_SKIP_BLOCKS=1
;;
-   OM5P|MR600|MR900)
+   OM5P|MR600|MR900|MR1750)
MAX_PART_SIZE=7808
KERNEL_FLASH_ADDR=0xb
FLASH_BS=65536
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/4] Build static version of libblobmsg_json

[Bachtin, Dmitri]

Signed-off-by: Dmitri Bachtin 
---
 CMakeLists.txt |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ecca3e9..65819c3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -47,13 +47,18 @@ IF(EXISTS ${json})
ADD_LIBRARY(blobmsg_json SHARED blobmsg_json.c)
TARGET_LINK_LIBRARIES(blobmsg_json ubox ${json})
 
+   ADD_LIBRARY(blobmsg_json-static STATIC blobmsg_json.c)
+   SET_TARGET_PROPERTIES(  blobmsg_json-static
+   PROPERTIES OUTPUT_NAME blobmsg_json)
+
ADD_EXECUTABLE(jshn jshn.c)
TARGET_LINK_LIBRARIES(jshn blobmsg_json ${json})
 
ADD_LIBRARY(json_script SHARED json_script.c)
TARGET_LINK_LIBRARIES(json_script ubox)
 
-   INSTALL(TARGETS blobmsg_json jshn json_script
+   INSTALL(TARGETS blobmsg_json blobmsg_json-static jshn json_script
+   ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib
RUNTIME DESTINATION bin
)
-- 
1.7.2.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/4] Search for libjson along with libjson-c

[Felix Fietkau]

On 2015-09-09 09:23, Bachtin, Dmitri wrote:
> Signed-off-by: Dmitri Bachtin 
Which libjson is this? The old version of json-c?

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

[OpenWrt-Devel] [PATCH v2 7/8] ar71xx: create profile and build image for the OpenMesh MR1750 board

[Sven Eckelmann]

Signed-off-by: Sven Eckelmann 
---
v2:
 - rebased on top of r46832

 target/linux/ar71xx/generic/profiles/openmesh.mk | 13 -
 target/linux/ar71xx/image/Makefile   |  3 ++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/target/linux/ar71xx/generic/profiles/openmesh.mk 
b/target/linux/ar71xx/generic/profiles/openmesh.mk
index 41b462e..1c51e93 100644
--- a/target/linux/ar71xx/generic/profiles/openmesh.mk
+++ b/target/linux/ar71xx/generic/profiles/openmesh.mk
@@ -49,9 +49,20 @@ endef
 
 $(eval $(call Profile,MR900))
 
+define Profile/MR1750
+NAME:=OpenMesh MR1750
+PACKAGES:=kmod-ath9k kmod-ath10k
+endef
+
+define Profile/MR1750/Description
+Package set optimized for the OpenMesh MR1750.
+endef
+
+$(eval $(call Profile,MR1750))
+
 define Profile/OPENMESH
NAME:=OpenMesh products
-   PACKAGES:=kmod-ath9k om-watchdog
+   PACKAGES:=kmod-ath9k kmod-ath10k om-watchdog
 endef
 
 define Profile/OPENMESH/Description
diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index e6fe36a..bc3afcd 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -2149,6 +2149,7 @@ $(eval $(call 
SingleProfile,OpenMesh,squashfs-only,OM2P,om2pOM2P))
 $(eval $(call SingleProfile,OpenMesh,squashfs-only,OM5P,om5pOM5P))
 $(eval $(call SingleProfile,OpenMesh,squashfs-only,MR600,mr600MR600))
 $(eval $(call SingleProfile,OpenMesh,squashfs-only,MR900,mr900MR900))
+$(eval $(call SingleProfile,OpenMesh,squashfs-only,MR1750,mr1750MR1750))
 
 $(eval $(call SingleProfile,PB4X,128k,ALL0305,all0305,ALL0305,ttyS0,115200))
 $(eval $(call SingleProfile,PB4X,128k,EAP7660D,eap7660d,EAP7660D,ttyS0,115200))
@@ -2224,7 +2225,7 @@ $(eval $(call MultiProfile,AP143,AP143_8M AP143_16M))
 $(eval $(call MultiProfile,AP147,AP147_010))
 $(eval $(call MultiProfile,DIR615IX,DIR615I1 DIR615I3))
 $(eval $(call MultiProfile,EWDORIN, EWDORINAP EWDORINRT EWDORIN16M))
-$(eval $(call MultiProfile,OPENMESH,OM2P OM5P MR600 MR900))
+$(eval $(call MultiProfile,OPENMESH,OM2P OM5P MR600 MR900 MR1750))
 $(eval $(call MultiProfile,TEW652BRP,TEW652BRP_FW TEW652BRP_RECOVERY))
 $(eval $(call MultiProfile,TLMR3220,TLMR3220V1))
 $(eval $(call MultiProfile,TLMR3420,TLMR3420V1))
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] uqmi: Added CMake option BUILD_STATIC for a static uqmi build

[Bachtin, Dmitri]

Signed-off-by: Dmitri Bachtin 
---
 CMakeLists.txt |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3f67652..4a11544 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,14 +1,26 @@
 cmake_minimum_required(VERSION 2.6)
 
 PROJECT(uqmi C)
+
+OPTION(BUILD_STATIC OFF)
+
 ADD_DEFINITIONS(-Os -ggdb -Wall -Werror --std=gnu99 -Wmissing-declarations 
-Wno-enum-conversion)
 
 SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
 
 SET(SOURCES main.c dev.c commands.c qmi-message.c)
 
-FIND_LIBRARY(json json-c json)
-SET(LIBS ubox blobmsg_json ${json})
+IF(BUILD_STATIC)
+  FIND_LIBRARY(json NAMES libjson.a libjson-c.a)
+  FIND_LIBRARY(blobmsg_json NAMES libblobmsg_json.a)
+  FIND_LIBRARY(ubox NAMES libubox.a)
+ELSE(BUILD_STATIC)
+  FIND_LIBRARY(json NAMES json-c json)
+  FIND_LIBRARY(blobmsg_json NAMES blobmsg_json)
+  FIND_LIBRARY(ubox NAMES ubox)
+ENDIF(BUILD_STATIC)
+
+SET(LIBS ${ubox} ${blobmsg_json} ${json})
 
 IF(DEBUG_PACKET)
   ADD_DEFINITIONS(-DDEBUG_PACKET)
-- 
1.7.2.5
___
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] blobmsg_add_json_from_file(): fixed const-correctness with libjson

[Felix Fietkau]

On 2015-09-09 09:23, Bachtin, Dmitri wrote:
> libjson's json_object_from_file takes a non-const char buffer as
> its second parameter while libjson-c takes a const one. Use
> strdup() to avoid using const data as non-const.
> 
> Signed-off-by: Dmitri Bachtin 
> ---
>  blobmsg_json.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index ffde23d..de876cf 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -97,7 +97,10 @@ out:
>  
>  bool blobmsg_add_json_from_file(struct blob_buf *b, const char *file)
>  {
> - return __blobmsg_add_json(b, json_object_from_file(file));
> + char* __file = strdup(file);
> + bool result = __blobmsg_add_json(b, json_object_from_file(__file));
> + free(__file);
> + return result;
I think the non-const parameter of json_object_from_file is a bug, and
in that case, a cast is better than a completely unnecessary strdup().

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

[OpenWrt-Devel] [PATCH v2 5/8] package/om-watchdog: add OpenMesh MR1750 support

[Sven Eckelmann]

Signed-off-by: Sven Eckelmann 
---
v2:
 - rebased on top of r46832

 package/kernel/om-watchdog/files/om-watchdog.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/om-watchdog/files/om-watchdog.init 
b/package/kernel/om-watchdog/files/om-watchdog.init
index 135fef7..c792968 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -25,7 +25,7 @@ boot() {
"mr600v2")
service_start /sbin/om-watchdog 15
;;
-   "mr900"|"mr900v2")
+   "mr900"|"mr900v2"|"mr1750")
service_start /sbin/om-watchdog 16
;;
esac
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [package] firewall: Redirect incoming WAN traffic only when destination IP address matches the IP address used for masquerading

[Alin Năstac]

This is a git patch for the firewall3 git repo at git://nbd.name/firewall3.git

Basically it prevents zone_wan_prerouting rules to affect traffic
towards IP addresses that are not used for masquerading LAN private IP
space and it does that by setting destination IP address of the
delegate_prerouting rules for zone with masq enabled to whatever
address(es) that particular network interface has.

The typical scenario this patch fixes involves 2 LAN network prefixes:
  - the usual 192.168.1.0/24 which is masqueraded by the public IP
address configured on the WAN interface
  - a public IP network prefix for those LAN devices that are supposed
to be excluded from NAT
Without this patch, port forwarding rules introduced for 192.168.1.x
LAN devices will also affect traffic towards the 2nd prefix.

>From 56820e2e3e09f68e4f9a74e6aff832fbcf2c5729 Mon Sep 17 00:00:00 2001
From: Alin Nastac 
Date: Fri, 4 Sep 2015 13:54:10 +0200
Subject: [PATCH] Redirect incoming WAN traffic only when
 destination IP address matches the IP address configured on the
incoming interface

---
 zones.c | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/zones.c b/zones.c
index 2ddd7b4..8bd6673 100644
--- a/zones.c
+++ b/zones.c
@@ -383,10 +383,38 @@ print_interface_rule(struct fw3_ipt_handle
*handle, struct fw3_state *state,
{
if (has(zone->flags, handle->family, FW3_FLAG_DNAT))
{
-   r = fw3_ipt_rule_create(handle, NULL, dev,
NULL, sub, NULL);
-   fw3_ipt_rule_target(r, "zone_%s_prerouting",
zone->name);
-   fw3_ipt_rule_extra(r, zone->extra_src);
-   fw3_ipt_rule_replace(r, "delegate_prerouting");
+   struct list_head *addrs;
+   struct fw3_address *addr;
+
+   addrs = zone->masq ? calloc(1, sizeof(*addrs)) : NULL;
+   if (addrs)
+   {
+   /* redirect only the traffic towards a
locally configured address */
+   INIT_LIST_HEAD(addrs);
+   fw3_ubus_address(addrs, dev->network);
+
+   list_for_each_entry(addr, addrs, list)
+   {
+   if (!fw3_is_family(addr,
handle->family))
+   continue;
+   /* reset mask to its maximum value */
+   memset(>mask.v6, 0xFF,
sizeof(addr->mask.v6));
+
+   r =
fw3_ipt_rule_create(handle, NULL, dev, NULL, sub, addr);
+   fw3_ipt_rule_target(r,
"zone_%s_prerouting", zone->name);
+   fw3_ipt_rule_extra(r, zone->extra_src);
+   fw3_ipt_rule_replace(r,
"delegate_prerouting");
+   }
+
+   fw3_free_list(addrs);
+   }
+   else
+   {
+   r = fw3_ipt_rule_create(handle, NULL,
dev, NULL, sub, NULL);
+   fw3_ipt_rule_target(r,
"zone_%s_prerouting", zone->name);
+   fw3_ipt_rule_extra(r, zone->extra_src);
+   fw3_ipt_rule_replace(r, "delegate_prerouting");
+   }
}

if (has(zone->flags, handle->family, FW3_FLAG_SNAT))
--
1.7.12.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] uqmi: Added CMake option BUILD_STATIC for a static uqmi build

[John Crispin]

On 09/09/2015 09:35, Bachtin, Dmitri wrote:
> Signed-off-by: Dmitri Bachtin 


Hi,

it is always nice if a patch has a short description that goes beyond
the subject. in this case it would be nice if you could explain why you
need to build a static version of uqmi

John






> ---
>  CMakeLists.txt |   16 ++--
>  1 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 3f67652..4a11544 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -1,14 +1,26 @@
>  cmake_minimum_required(VERSION 2.6)
>  
>  PROJECT(uqmi C)
> +
> +OPTION(BUILD_STATIC OFF)
> +
>  ADD_DEFINITIONS(-Os -ggdb -Wall -Werror --std=gnu99 -Wmissing-declarations 
> -Wno-enum-conversion)
>  
>  SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
>  
>  SET(SOURCES main.c dev.c commands.c qmi-message.c)
>  
> -FIND_LIBRARY(json json-c json)
> -SET(LIBS ubox blobmsg_json ${json})
> +IF(BUILD_STATIC)
> +  FIND_LIBRARY(json NAMES libjson.a libjson-c.a)
> +  FIND_LIBRARY(blobmsg_json NAMES libblobmsg_json.a)
> +  FIND_LIBRARY(ubox NAMES libubox.a)
> +ELSE(BUILD_STATIC)
> +  FIND_LIBRARY(json NAMES json-c json)
> +  FIND_LIBRARY(blobmsg_json NAMES blobmsg_json)
> +  FIND_LIBRARY(ubox NAMES ubox)
> +ENDIF(BUILD_STATIC)
> +
> +SET(LIBS ${ubox} ${blobmsg_json} ${json})
>  
>  IF(DEBUG_PACKET)
>ADD_DEFINITIONS(-DDEBUG_PACKET)
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/4] Build static version of libblobmsg_json

[Bachtin, Dmitri]

> Why?

A libblobmsg_json.a would follow the same rule as with libubox.a already 
present in the CMakeLists.txt and allows consistent -dev packages I'd like to 
maintain for Debian in the future.

The reason is that Debian's Squeeze (oldstable) is still supported until Feb 
2016. While it isn't a long time frame anymore, it will still be consistent to 
support all currently available versions if it is possible directly.

Greetings,
 -- Dmitri Bachtin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] generic: Fix per interface nf_call_iptables setting

[Sven Eckelmann]

commit r30917 ("kernel: bypass all netfilter hooks if the sysctls for that
functionality have been disabled - eliminates the overhead of enabling
CONFIG_BRIDGE_NETFILTER in the kernel config") introduced an optimization
which should reduce/eliminate the overhead for traffic send over bridges on
kernels compiled with CONFIG_BRIDGE_NETFILTER=y. But this optimization
breaks the nf_call_iptables per bridge setting which is more fine grained
than the global sysctl net.bridge.bridge-nf-call-iptables setting.

A test reflecting a real world setup was created to identify if this really
eliminates the overhead and if per-bridge nf_call_iptables could be used in
some setups to increase the throughput. A Qualcomm Atheros QCA9558 based
system with one ethernet and an ath9k wifi 3x3 in HT40 mode was used.
Cables from the AP to the wifi station were used to reduce interference
problems during the tests.

The wlan interface was put in one bridge interface called br-wlan. This
bridge usually contains some more wlan interfaces. The eth0 was put in a
second bridge called br-lan. This usually contains some other privileged
wlan or mesh interfaces. Routing was added between br-lan and br-wlan.

Three kernels were tested:

 * (default) OpenWrt kernel for this device
 * (brfilter-global) OpenWrt kernel with CONFIG_BRIDGE_NETFILTER=y
 * (brfilter-local)  OpenWrt kernel with CONFIG_BRIDGE_NETFILTER=y and
without 644-bridge_optimize_netfilter_hooks.patch

The changes to the the netfilter settings of the bridge were done via:

 * (brfilter-global) /sbin/sysctl -w net.bridge.bridge-nf-call-iptables=1
 * (brfilter-lobal) echo 1 > /sys/class/net/br-lan/bridge/nf_call_iptables
   and/or echo 1 > /sys/class/net/br-wan/bridge/nf_call_iptables

A station connected to the wlan0 (AP) interface was used to send traffic to
a PC connected via ethernet. iperf with 3 concurrent transmissions was used
to generate the traffic.

| kernel  | br-nf-* global | nf-call* iface | download | upload   |
|-|||--|--|
| default | 0  | -  |  209 |  268 |
| brfilter-global | 0  | -  |  185 |  243 |
| brfilter-local  | 0  | -  |  187 |  243 |
| brfilter-local  | 0  | br-lan |  157 |  226 |
| brfilter-local  | 0  | br-lan br-wlan |  139 |  161 |
| brfilter-global | 1  | -  |  136 |  162 |

Download/upload results in Mibit/s

It can be seen that the patch doesn't eliminate the overhead. It can also
be seen that the throughput of brfilter-global and brfilter-local with
disabled filtering is the roughly the same. Also the throughput for
brfilter-global and brfilter-local for enabled filtering on all bridges is
roughly the same.

But also the brfilter-local throughput is higher when only br-lan requires
the filtering. This setting would not be possible with
644-bridge_optimize_netfilter_hooks.patch applied and thus can only be
compared with brfilter-global and filtering enabled for all interfaces.

Signed-off-by: Sven Eckelmann 
---
v2:
 - rebased on top of r46832

original discussion (+ more results and pictures) can be found under
 http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/34535

 .../644-bridge_optimize_netfilter_hooks.patch  | 179 -
 .../644-bridge_optimize_netfilter_hooks.patch  | 179 -
 .../644-bridge_optimize_netfilter_hooks.patch  | 179 -
 3 files changed, 537 deletions(-)
 delete mode 100644 
target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch
 delete mode 100644 
target/linux/generic/patches-4.0/644-bridge_optimize_netfilter_hooks.patch
 delete mode 100644 
target/linux/generic/patches-4.1/644-bridge_optimize_netfilter_hooks.patch

diff --git 
a/target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch 
b/target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch
deleted file mode 100644
index 3572661..000
--- 
a/target/linux/generic/patches-3.18/644-bridge_optimize_netfilter_hooks.patch
+++ /dev/null
@@ -1,179 +0,0 @@
-From: Felix Fietkau 
-Subject: [PATCH] bridge: optimize netfilter hooks
-
-Bypass all netfilter hooks if the sysctls for that functionality have
-been disabled - eliminates the overhead of enabling
-CONFIG_BRIDGE_NETFILTER in the kernel config

 a/net/bridge/br_forward.c
-+++ b/net/bridge/br_forward.c
-@@ -53,7 +53,7 @@ EXPORT_SYMBOL_GPL(br_dev_queue_push_xmit
- 
- int br_forward_finish(struct sk_buff *skb)
- {
--  return NF_HOOK(NFPROTO_BRIDGE, NF_BR_POST_ROUTING, skb, NULL, skb->dev,
-+  return BR_HOOK(NFPROTO_BRIDGE, NF_BR_POST_ROUTING, skb, NULL, skb->dev,
-  br_dev_queue_push_xmit);
- 
- }
-@@ -77,7 +77,7 @@ static void __br_deliver(const struct ne
-   

Re: [OpenWrt-Devel] [PATCH 3/4] Search for libjson along with libjson-c

[Bachtin, Dmitri]

> This patch probably require further checks. Please take a look at commit
> cbf80de7f4df61960f386cb01a899cf4228d38f3 for more information.

> - Felix

I see. That makes sense. 

Please ignore then the patches 3 + 4 and the uqmi patch in the next thread. I 
think that they are better suited for distro-specific patches handled by a 
maintainer.

Thank you for reviewing the changes so quickly!

Sincerely,
 -- Dmitri Bachtin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] AR9344 OpenWrt GUI

[John kerry]

Hi,

We are working on AR9344 OpenWrt,

We have configured the wireless as AP mode and broadcasting the SSID so any
device can connect to it and even we are able access the GUI on Smartphone
after connecting to that AP.

Then we do survey the scanning devices, its gives the Scanning result, then
we can join Network  to anyone from the list. Then blow page will show as
shown below:


[image: Inline image 1]


The we enter the PassPhrase and Click on Submit button. Then next page will
show as below
[image: Inline image 2]

After Clicking the on *Save & Apply button, *The following files
/etc/config/network

/etc/config/dhcp, /etc/config/qos etc.

Because of this files changes Wi-Fi connection is reset the connection. So
we are unable to configure above configuration using Smartphone.



Could anyone please help us to solve this issue.


Regards,
___
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] blobmsg_add_json_from_file(): fixed const-correctness with libjson

[Bachtin, Dmitri]

> I think the non-const parameter of json_object_from_file is a bug, and in 
> that case, a cast is better than a completely unnecessary strdup().
> 
> - Felix

I've checked the source of json_object_from_file(char*) and the buffer walks 
directly into open(3) and vsyslog(3). open(3) takes a const buffer while 
vsyslog(3) takes a varargs list which doesn't tinker with the buffer, too.

You are completely right, Felix, and a cast is enough.
 -- Dmitri Bachtin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

[Felix Fietkau]

On 2015-09-09 13:01, John kerry wrote:
> Hi,
> 
> We are working on AR9344 OpenWrt,
> 
> We have configured the wireless as AP mode and broadcasting the SSID so
> any device can connect to it and even we are able access the GUI on
> Smartphone after connecting to that AP.
> 
> Then we do survey the scanning devices, its gives the Scanning result,
> then we can join Network  to anyone from the list. Then blow page will
> show as shown below:
> 
> 
> Inline image 1
> 
> 
> The we enter the PassPhrase and Click on Submit button. Then next page
> will show as below
> 
> Inline image 2
> 
> After Clicking the on *Save & Apply button, *The following files
> /etc/config/network
> 
> /etc/config/dhcp, /etc/config/qos etc.
> 
> Because of this files changes Wi-Fi connection is reset the connection.
> So we are unable to configure above configuration using Smartphone.
> 
>  
> 
> Could anyone please help us to solve this issue.
You forgot to mention which OpenWrt version you are using. Based on the
screenshots it seems to me that you're still using some fork of OpenWrt
with a proprietary wifi driver. If that is the case, we can't help you,
you're on your own.

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

[OpenWrt-Devel] [PATCH netifd 1/6] device: Resolve ifindex for external claimed devices

[Hans Dedecker]

Fixes regression issues introduced by commit 3224b80 as external (PPP)
device ifindex was not in sync with kernel device ifindex due to re-creation
of the device by the PPP daemon

Signed-off-by: Hans Dedecker 
---
 device.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/device.c b/device.c
index 21b436f..a29c981 100644
--- a/device.c
+++ b/device.c
@@ -74,15 +74,14 @@ void device_unlock(void)
 static int set_device_state(struct device *dev, bool state)
 {
if (state) {
-   /* Set ifindex for all devices being enabled so a valid  */
+   /* Get ifindex for all devices being enabled so a valid  */
/* ifindex is in place avoiding possible race conditions */
device_set_ifindex(dev, system_if_resolve(dev));
if (!dev->ifindex)
return -1;
-   }
 
-   if (state)
system_if_up(dev);
+   }
else
system_if_down(dev);
 
@@ -332,7 +331,13 @@ int device_claim(struct device_user *dep)
return 0;
 
device_broadcast_event(dev, DEV_EVENT_SETUP);
-   if (!dev->external)
+   if (dev->external) {
+   /* Get ifindex for external claimed devices so a valid   */
+   /* ifindex is in place avoiding possible race conditions */
+   device_set_ifindex(dev, system_if_resolve(dev));
+   if (!dev->ifindex)
+   ret = -1;
+   } else
ret = dev->set_state(dev, true);
 
if (ret == 0)
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd 2/6] iprule: Insert network and address ip rules before main table lookup rule

[Hans Dedecker]

Specific IP address and network rules are now checked before the main table 
lookup as the main table
often holds a default route. As a result the IP address and network rules 
pointing to s specific
routing table will not be checked anymore; by reversing the order the specific 
routing tables
are checked first if the ip rule matches.

Signed-off-by: Hans Dedecker 
---
 iprule.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/iprule.h b/iprule.h
index b4b124c..e1ac84b 100644
--- a/iprule.h
+++ b/iprule.h
@@ -17,8 +17,8 @@
 
 #include "interface-ip.h"
 
-#define IPRULE_PRIORITY_ADDR 8
-#define IPRULE_PRIORITY_NW 9
+#define IPRULE_PRIORITY_ADDR 1
+#define IPRULE_PRIORITY_NW 2
 #define IPRULE_PRIORITY_REJECT 42
 
 enum iprule_flags {
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd 3/6] interface-ip: Remove ip loop policy rules as kernel issue is fixed

[Hans Dedecker]

Remove ip loop policy rules as workaround for the kernel using unspecified 
address
to lookup locally originating traffic is fixed by 
http://lkml.iu.edu/hypermail/linux/kernel/1505.0/03094.html

Signed-off-by: Hans Dedecker 
---
 interface-ip.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/interface-ip.c b/interface-ip.c
index 7f8a451..6c152b6 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -133,23 +133,6 @@ static int set_ip_source_policy(bool add, bool v6, 
unsigned int priority,
return (add) ? system_add_iprule() : system_del_iprule();
 }
 
-static int set_ip_lo_policy(bool add, bool v6, struct interface *iface)
-{
-   struct iprule rule = {
-   .flags = IPRULE_IN | IPRULE_LOOKUP | IPRULE_PRIORITY,
-   .priority = IPRULE_PRIORITY_NW + iface->l3_dev.dev->ifindex,
-   .lookup = (v6) ? iface->ip6table : iface->ip4table,
-   .in_dev = "lo"
-   };
-
-   if (!rule.lookup)
-   return 0;
-
-   rule.flags |= (v6) ? IPRULE_INET6 : IPRULE_INET4;
-
-   return (add) ? system_add_iprule() : system_del_iprule();
-}
-
 static bool
 __find_ip_addr_target(struct interface_ip_settings *ip, union if_addr *a, bool 
v6)
 {
@@ -1258,13 +1241,9 @@ void interface_ip_set_enabled(struct 
interface_ip_settings *ip, bool enabled)
if (!strcmp(a->name, ip->iface->name))
interface_set_prefix_address(a, c, ip->iface, 
enabled);
 
-   if (ip->iface && ip->iface->l3_dev.dev) {
-   set_ip_lo_policy(enabled, true, ip->iface);
-   set_ip_lo_policy(enabled, false, ip->iface);
-
+   if (ip->iface && ip->iface->l3_dev.dev)
set_ip_source_policy(enabled, true, IPRULE_PRIORITY_REJECT + 
ip->iface->l3_dev.dev->ifindex,
NULL, 0, 0, ip->iface, "failed_policy");
-   }
 }
 
 void
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ?

[Etienne Champetier]

2015-09-09 15:20 GMT+02:00 Hannu Nyman :

> I repeat my earlier wish that trunk should be renamed as soon as possible.
>
> There has been several changes during the summer that have made trunk to
> significantly deviate from the CC branch. Some of the changes are under the
> hood (like musl vs. uClibc), but especially the recent telnet removal is
> rather prominent change for users. From documentation / advice / forum
> discussion perspective it is rather frustrating that both trunk and 15.05
> are still referenced as "Chaos Calmer".
>
> Having trunk renamed to something Dxxx Dxxx would clarify things.
>
> +1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Renaming trunk to Dxx Dxx ?

[Hannu Nyman]

I repeat my earlier wish that trunk should be renamed as soon as possible.

There has been several changes during the summer that have made trunk to 
significantly deviate from the CC branch. Some of the changes are under the 
hood (like musl vs. uClibc), but especially the recent telnet removal is 
rather prominent change for users. From documentation / advice / forum 
discussion perspective it is rather frustrating that both trunk and 15.05 are 
still referenced as "Chaos Calmer".


Having trunk renamed to something Dxxx Dxxx would clarify things.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd 5/6] interface-ip: Don't create ip network rule if address mask is equal to full mask

[Hans Dedecker]

Prevents the creation of identical address and network IP rules

Signed-off-by: Hans Dedecker 
---
 interface-ip.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/interface-ip.c b/interface-ip.c
index 43b63c7..d5f6aff 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -513,8 +513,10 @@ interface_update_proto_addr(struct vlist_tree *tree,
if (table) {
set_ip_source_policy(false, v6, 
IPRULE_PRIORITY_ADDR, _old->addr,
(v6) ? 128 : 32, table, NULL, 
NULL);
-   set_ip_source_policy(false, v6, 
IPRULE_PRIORITY_NW, _old->addr,
-   a_old->mask, table, NULL, NULL);
+
+   if (a_old->mask != ((v6) ? 128 : 32))
+   set_ip_source_policy(false, v6, 
IPRULE_PRIORITY_NW, _old->addr,
+   a_old->mask, table, 
NULL, NULL);
}
 
if (!(a_old->flags & DEVADDR_EXTERNAL)) {
@@ -546,8 +548,10 @@ interface_update_proto_addr(struct vlist_tree *tree,
if (table) {
set_ip_source_policy(true, v6, 
IPRULE_PRIORITY_ADDR, _new->addr,
(v6) ? 128 : 32, table, 
NULL, NULL);
-   set_ip_source_policy(true, v6, 
IPRULE_PRIORITY_NW, _new->addr,
-   a_new->mask, table, 
NULL, NULL);
+
+   if (a_new->mask != ((v6) ? 128 : 32))
+   set_ip_source_policy(true, v6, 
IPRULE_PRIORITY_NW, _new->addr,
+   a_new->mask, 
table, NULL, NULL);
}
}
}
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd 6/6] interface-ip: Set route table when enabling interface ip settings

[Hans Dedecker]

Routes are now inserted in the correct routing table when interface ip4table 
and/or
ip6table was changed during interface_change_config

Signed-off-by: Hans Dedecker 
---
 interface-ip.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/interface-ip.c b/interface-ip.c
index d5f6aff..8eb2ff3 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -1234,6 +1234,15 @@ void interface_ip_set_enabled(struct 
interface_ip_settings *ip, bool enabled)
if (!(route->flags & DEVROUTE_METRIC))
route->metric = ip->iface->metric;
 
+   if (!(route->flags & DEVROUTE_TABLE)) {
+   route->flags &= ~DEVROUTE_SRCTABLE;
+   route->table = ((route->flags & DEVADDR_FAMILY) 
== DEVADDR_INET6) ?
+   iface->ip6table : 
iface->ip4table;
+
+   if (route->table)
+   route->flags |= DEVROUTE_SRCTABLE;
+   }
+
if (system_add_route(dev, route))
route->failed = true;
} else
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd 4/6] interface-ip: Insert network and address ip rules for external addresses as well

[Hans Dedecker]

Signed-off-by: Hans Dedecker 
---
 interface-ip.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/interface-ip.c b/interface-ip.c
index 6c152b6..43b63c7 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -500,9 +500,7 @@ interface_update_proto_addr(struct vlist_tree *tree,
}
 
if (node_old) {
-   if (!(a_old->flags & DEVADDR_EXTERNAL) && a_old->enabled && 
!keep) {
-   interface_handle_subnet_route(iface, a_old, false);
-
+   if (a_old->enabled && !keep) {
if ((a_old->flags & DEVADDR_FAMILY) == DEVADDR_INET6)
v6 = true;
 
@@ -519,7 +517,10 @@ interface_update_proto_addr(struct vlist_tree *tree,
a_old->mask, table, NULL, NULL);
}
 
-   system_del_address(dev, a_old);
+   if (!(a_old->flags & DEVADDR_EXTERNAL)) {
+   interface_handle_subnet_route(iface, a_old, 
false);
+   system_del_address(dev, a_old);
+   }
}
free(a_old->pclass);
free(a_old);
@@ -527,9 +528,14 @@ interface_update_proto_addr(struct vlist_tree *tree,
 
if (node_new) {
a_new->enabled = true;
-   if (!(a_new->flags & DEVADDR_EXTERNAL) && (!keep || replace)) {
-   if (system_add_address(dev, a_new))
-   a_new->failed = true;
+   if (!keep || replace) {
+   if (!(a_new->flags & DEVADDR_EXTERNAL)) {
+   if (system_add_address(dev, a_new))
+   a_new->failed = true;
+
+   if (iface->metric)
+   interface_handle_subnet_route(iface, 
a_new, true);
+   }
 
if (!keep) {
if ((a_new->flags & DEVADDR_FAMILY) == 
DEVADDR_INET6)
@@ -544,9 +550,6 @@ interface_update_proto_addr(struct vlist_tree *tree,
a_new->mask, table, 
NULL, NULL);
}
}
-
-   if (iface->metric)
-   interface_handle_subnet_route(iface, a_new, 
true);
}
}
 }
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

[Tobias Welz]

We ran into this issue recently, where the switch to musl subtly changed the regexp 
behavior of grep, and where it took a while to realize that the reporter was on musl while all 
other testing machines where not. Having had a "DD rNN” version string somewhere 
early in the report might have helped figuring out the root cause faster… ("Chaos Chalmer 
Bleeding Edge" in retrospect should have been signal enough, but it was not).
BTW: Why does the trunk has to be "renamed". The trunk is always recent, 
so it could also have a persistent name like "Bleeding Edge" (BTW: is 
this a cocktail?) and it would be always clear, that you are on the 
trunk. Similar like Debian Unstable (trunk) is always called "Sid".


Or at least there should always be an addon on the name, like mentioned 
before "Xxxx Xxxx Bleeding Edge".
Even I use OpenWrt since Whiterussian, this is the first time I ran into 
this pitfall.
I recently submitted a patch and it was absolutely not clear, why the 
patch will not directly end up in "Chaos Calmer" (Release) when it had 
been submitted to "Chaos Calmer" (Trunk).


So I absolutely vote for some clear consistent naming of the trunk and 
seperate names for the releases. (What about some Cocktail with a letter 
from the end of the alphabet like Z Z or X X in case 
there exists one)





but especially the recent telnet removal is rather prominent change for users. From 
documentation / advice / forum discussion perspective it is rather frustrating that both 
trunk and 15.05 are still referenced as "Chaos Calmer".

Having trunk renamed to something Dxxx Dxxx would clarify things.

+1

+1  (that there should be some renaming soon - to discuss what is best)



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

[OpenWrt-Devel] [PATCH] ar71xx: add TP-LINK TL-WDR3320 v2 support

[Weijie Gao]

Signed-off-by: Weijie Gao 

This patch adds support for TP-LINK TL-WDR3320 v2.

This router uses a chinese version 2 firmware header,.
---
 target/linux/ar71xx/base-files/etc/diag.sh |   1 +
 .../ar71xx/base-files/etc/uci-defaults/01_leds |   4 +
 .../ar71xx/base-files/etc/uci-defaults/02_network  |   1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   6 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ar71xx/config-4.1 |   1 +
 .../files/arch/mips/ath79/mach-tl-wdr3320-v2.c | 146 +
 target/linux/ar71xx/generic/profiles/tp-link.mk|  11 ++
 target/linux/ar71xx/image/Makefile |  46 ++-
 .../816-MIPS-ath79-add-tl-wdr3320-v2-support.patch |  40 ++
 10 files changed, 256 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c
 create mode 100644 
target/linux/ar71xx/patches-4.1/816-MIPS-ath79-add-tl-wdr3320-v2-support.patch

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 36de775..0dcc844 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -256,6 +256,7 @@ get_status_led() {
tl-wa901nd | \
tl-wa901nd-v2 | \
tl-wa901nd-v3 | \
+   tl-wdr3320-v2 | \
tl-wdr3500 | \
tl-wr1041n-v2 | \
tl-wr1043nd | \
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index e7f7a4c..4dafc1e 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -425,6 +425,10 @@ tl-wa901nd-v2)
ucidef_set_led_wlan "wlan" "WLAN" "tp-link:green:wlan" "phy0tpt"
;;
 
+tl-wdr3320-v2)
+   ucidef_set_led_wlan "wlan5g" "WLAN5G" "tp-link:green:wlan5g" "phy0tpt"
+   ;;
+
 tl-wdr3500)
ucidef_set_led_usbdev "usb" "USB" "tp-link:green:usb" "1-1"
ucidef_set_led_wlan "wlan2g" "WLAN2G" "tp-link:green:wlan2g" "phy0tpt"
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 686fce9..37d5a63 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -435,6 +435,7 @@ tew-712br |\
 tl-mr3220 |\
 tl-mr3220-v2 |\
 tl-mr3420 |\
+tl-wdr3320-v2 |\
 tl-wdr3500 |\
 tl-wr741nd |\
 tl-wr741nd-v4 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index e1f345e..c5440f9 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -221,6 +221,9 @@ tplink_board_detect() {
"342000"*)
model="TP-Link TL-MR3420"
;;
+   "332000"*)
+   model="TP-Link TL-WDR3320"
+   ;;
"35"*)
model="TP-Link TL-WDR3500"
;;
@@ -763,6 +766,9 @@ ar71xx_board_detect() {
*"TL-WA901ND v3")
name="tl-wa901nd-v3"
;;
+   *"TL-WDR3320 v2")
+   name="tl-wdr3320-v2"
+   ;;
*"TL-WDR3500")
name="tl-wdr3500"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index c1962e4..1d56d99 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -338,6 +338,7 @@ platform_check_image() {
tl-wa901nd | \
tl-wa901nd-v2 | \
tl-wa901nd-v3 | \
+   tl-wdr3320-v2 | \
tl-wdr3500 | \
tl-wdr4300 | \
tl-wdr4900-v2 | \
diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
index 21c4601..d0a6602 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -121,6 +121,7 @@ CONFIG_ATH79_MACH_TL_WA830RE_V2=y
 CONFIG_ATH79_MACH_TL_WA901ND=y
 CONFIG_ATH79_MACH_TL_WA901ND_V2=y
 CONFIG_ATH79_MACH_TL_WAX50RE=y
+CONFIG_ATH79_MACH_TL_WDR3320_V2=y
 CONFIG_ATH79_MACH_TL_WDR3500=y
 CONFIG_ATH79_MACH_TL_WDR4300=y
 CONFIG_ATH79_MACH_TL_WDR6500_V2=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c
new file mode 100644
index 000..3e452f2
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3320-v2.c
@@ -0,0 +1,146 @@
+/*
+ *  TP-LINK TL-WDR3320 v2 board support
+ *
+ *  Copyright (C) 2012 Gabor Juhos 
+ *  Copyright (C) 2015 Weijie Gao 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software 

[OpenWrt-Devel] Removing Telnet

[Ben Franske]

A couple of thoughts on some of the discussion around this:

1) I would be a proponent of a pre-set password, SSH without a password 
is very unusual behavior. I understand that there have been some 
comments "Any preset password is asking for users to
leave it default." I fail to see how this is any more true for a default 
password compared with no password. Having no password is asking for 
people to leave it without any password at all. Therefore I would 
suggest that a preset password is no worse in terms of getting the 
password changed than having no password. In the past the incentive to 
set a password was to enable SSH but that will no longer be the case so 
I see no disadvantage to having a pre-set password (which will provide a 
better user experience as it's more "normal").


2) If there is a great concern about getting people to change passwords 
then there should be a first boot script which launches passwd for them 
the first time they connect. There are disadvantages to this as well no 
doubt but it would be worth discussing if you want to force a password 
set/change.


3) For those looking to run automated device setup scripts... I think 
it's time to come up with new plan, there are lots of options. If you 
are provisioning a large number of devices I would argue you should be 
creating a custom image anyway. That custom image could easily include a 
first boot script which automatically pulls some configuration files 
from an HTTP/HTTPS server or a FTP/TFTP server or any one of the other 
multitude of ways you could do this. Automatic device provisioning is a 
pretty well understood problem (see VoIP phones for example) and easily 
solvable. If you're not currently building custom images it's a bit more 
of a headache, but you probably should be anyway because there are some 
real advantages to it for multiple device initialization anyway.


4) If there is enough interest in automatic provisioning on first boot 
it might be possible to try and build it into the standard OpenWRT image 
too.


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

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

[David Lang]

On Wed, 9 Sep 2015, John kerry wrote:


Hi,

We are working on AR9344 OpenWrt,

We have configured the wireless as AP mode and broadcasting the SSID so any
device can connect to it and even we are able access the GUI on Smartphone
after connecting to that AP.

Then we do survey the scanning devices, its gives the Scanning result, then
we can join Network  to anyone from the list. Then blow page will show as
shown below:


[image: Inline image 1]


The we enter the PassPhrase and Click on Submit button. Then next page will
show as below
[image: Inline image 2]

After Clicking the on *Save & Apply button, *The following files
/etc/config/network

/etc/config/dhcp, /etc/config/qos etc.

Because of this files changes Wi-Fi connection is reset the connection. So
we are unable to configure above configuration using Smartphone.


Well, when you reconfigure the interface you are connected to, it is going to 
bounce. Which is why it's suggested that you configure the wireless through a 
wired link.


But once the wifi is reset, you should be able to reconnect, login again and 
continue. Is this not working? If not, what is happening?


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Ben Franske]

I'm copying this to the list because it was sent directly to me... There 
are definitely many ways of "encouraging" people to change the password 
which could be explored, another example is the WAN interface could be 
disabled until the password is set. A few more thoughts on something 
like that or the WiFi disable proposed below though:


-Don't just have a feature like WiFi die without an error message 
indicating the password must be changed, again bad user experience (and 
lots of support requests)
-Make sure that the error is clear BOTH in LuCI and the CLI and provide 
instructions for changing the password (e.g. just sending an error to 
the console is not sufficient) LuCI already can detect the null password 
condition as it prompts the user with a banner to set a password, this 
could be adapted to check for a default password and the warn the user 
that some features are disabled until the password is changed


-Ben

On 9/9/2015 6:05 PM, Derek & Vicky wrote:
I agree no password is problematic, so is a default password that 
never gets changed.  So what if the wifi startup script checks the 
md5sum of the /etc/shadow file against the sum it created at startup 
Or predefined value.  This way it won't enable the wifi unless the sum 
changes.


Derek

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

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

[John kerry]

Hi,

Yes after reset we are to able to reconnect, I understand using wired
connection we can configure but we need to configure using wireless only.
Is there anyway that we can avoid the Wi-Fi reset?

Regards,

On Thu, Sep 10, 2015 at 7:29 AM, David Lang  wrote:

> On Wed, 9 Sep 2015, John kerry wrote:
>
> Hi,
>>
>> We are working on AR9344 OpenWrt,
>>
>> We have configured the wireless as AP mode and broadcasting the SSID so
>> any
>> device can connect to it and even we are able access the GUI on Smartphone
>> after connecting to that AP.
>>
>> Then we do survey the scanning devices, its gives the Scanning result,
>> then
>> we can join Network  to anyone from the list. Then blow page will show as
>> shown below:
>>
>>
>> [image: Inline image 1]
>>
>>
>> The we enter the PassPhrase and Click on Submit button. Then next page
>> will
>> show as below
>> [image: Inline image 2]
>>
>> After Clicking the on *Save & Apply button, *The following files
>> /etc/config/network
>>
>> /etc/config/dhcp, /etc/config/qos etc.
>>
>> Because of this files changes Wi-Fi connection is reset the connection. So
>> we are unable to configure above configuration using Smartphone.
>>
>
> Well, when you reconfigure the interface you are connected to, it is going
> to bounce. Which is why it's suggested that you configure the wireless
> through a wired link.
>
> But once the wifi is reset, you should be able to reconnect, login again
> and continue. Is this not working? If not, what is happening?
>
> David Lang
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Sami Olmari]

IMHO no password is best method until a password is set (like it was with
telnet and now with new paswordless SSH). A default password is just false
sense of security, there is none! Otherwise "encouraging" to set one and
how can be discussed...

 Olmari

On Thu, Sep 10, 2015 at 3:14 AM, Ben Franske  wrote:

> I'm copying this to the list because it was sent directly to me... There
> are definitely many ways of "encouraging" people to change the password
> which could be explored, another example is the WAN interface could be
> disabled until the password is set. A few more thoughts on something like
> that or the WiFi disable proposed below though:
>
> -Don't just have a feature like WiFi die without an error message
> indicating the password must be changed, again bad user experience (and
> lots of support requests)
> -Make sure that the error is clear BOTH in LuCI and the CLI and provide
> instructions for changing the password (e.g. just sending an error to the
> console is not sufficient) LuCI already can detect the null password
> condition as it prompts the user with a banner to set a password, this
> could be adapted to check for a default password and the warn the user that
> some features are disabled until the password is changed
>
> -Ben
>
> On 9/9/2015 6:05 PM, Derek & Vicky wrote:
>
>> I agree no password is problematic, so is a default password that never
>> gets changed.  So what if the wifi startup script checks the md5sum of the
>> /etc/shadow file against the sum it created at startup Or predefined
>> value.  This way it won't enable the wifi unless the sum changes.
>>
>> Derek
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR9344 OpenWrt GUI

[John kerry]

Could anyone please help me to solve this issue. How we can avoid the wifi
reset.

On Thu, Sep 10, 2015 at 9:24 AM, John kerry  wrote:

> Hi,
>
> Yes after reset we are to able to reconnect, I understand using wired
> connection we can configure but we need to configure using wireless only.
> Is there anyway that we can avoid the Wi-Fi reset?
>
> Regards,
>
> On Thu, Sep 10, 2015 at 7:29 AM, David Lang  wrote:
>
>> On Wed, 9 Sep 2015, John kerry wrote:
>>
>> Hi,
>>>
>>> We are working on AR9344 OpenWrt,
>>>
>>> We have configured the wireless as AP mode and broadcasting the SSID so
>>> any
>>> device can connect to it and even we are able access the GUI on
>>> Smartphone
>>> after connecting to that AP.
>>>
>>> Then we do survey the scanning devices, its gives the Scanning result,
>>> then
>>> we can join Network  to anyone from the list. Then blow page will show as
>>> shown below:
>>>
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> The we enter the PassPhrase and Click on Submit button. Then next page
>>> will
>>> show as below
>>> [image: Inline image 2]
>>>
>>> After Clicking the on *Save & Apply button, *The following files
>>> /etc/config/network
>>>
>>> /etc/config/dhcp, /etc/config/qos etc.
>>>
>>> Because of this files changes Wi-Fi connection is reset the connection.
>>> So
>>> we are unable to configure above configuration using Smartphone.
>>>
>>
>> Well, when you reconfigure the interface you are connected to, it is
>> going to bounce. Which is why it's suggested that you configure the
>> wireless through a wired link.
>>
>> But once the wifi is reset, you should be able to reconnect, login again
>> and continue. Is this not working? If not, what is happening?
>>
>> David Lang
>>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ? Or seperate name for Trunk?

[Hannu Nyman]

Tobias Welz wrote at Wed Sep 9 17:24:14 CEST 2015:
> So I absolutely vote for some clear consistent naming of the trunk and 
seperate names for the releases. (What about some Cocktail with a letter from 
the end of the alphabet like Z Z or X X in case there exists one)


On that idea, the possible permanent name for the trunk could be something 
Txx Trunk. There are over 20 releases until TT is reached, so not for soon. I 
didn't find any really suitable drink names, but below are some ideas:

Trekking Trunk
Tasty Trunk
Tricky Trunk
Tempting Trunk
Twisty Trunk
Trunk Thrill
Thrilling Trunk

But until that, renaming trunk to something Dxxx Dxxx would be enough to 
decrease confusion.

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