Re: [OpenWrt-Devel] [PATCH 2/3] busybox: allow own class B range to be used for zeroconf

[Stam, Michel [FINT]]

Hey Felix,

I've already done this. My intention was to submit it to both OpenWRT
and Busybox, then add another commit to remove the patch once it is in a
busybox release.

See here:
OpenWRT commit -> busybox ticket

busybox/netifd: make zcip log to syslog (always) ->
https://bugs.busybox.net/show_bug.cgi?id=7502
busybox: allow own class B range to be used for zeroconf ->
https://bugs.busybox.net/show_bug.cgi?id=7496
busybox: add option for tweaking arpping to udhcpd ->
https://bugs.busybox.net/show_bug.cgi?id=7490


Kind regards,
Fugro Intersite B.V.

Michel Stam
Embedded System Engineer

T +31 (0)70 31 70575 | F  +31 (0)70 31 11890
m.s...@fugro.nl | www.fugro.com
Dillenburgsingel 69, 2263 HW Leidschendam | P.O. Box 154, 2260 AD
Leidschendam, The Netherlands
Trade Register nr 34048179 | VAT nr NL005621409B24
-Original Message-
From: Felix Fietkau [mailto:n...@openwrt.org] 
Sent: Friday, October 03, 2014 0:04 AM
To: Stam, Michel [FINT]; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH 2/3] busybox: allow own class B
range to be used for zeroconf

On 2014-10-02 15:41, Michel Stam wrote:
> 169.254 may be used by local networks. This patch allows specifying 
> your own IP range.
> 
> Signed-off-by: Michel Stam 
Could you please also submit this and the other patch to busybox
upstream?

Thanks,

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

[OpenWrt-Devel] [PATCH] Fix NETGEAR WNR2200 leds gpio and usb power

[郭涛]

Signed-off-by: Tao Guo 
---
 .../ar71xx/files/arch/mips/ath79/mach-wnr2200.c| 100 +
 1 file changed, 41 insertions(+), 59 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
index bf7f9ee..d06a2f4 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
@@ -14,7 +14,9 @@
 #include 

 #include 
+#include 

+#include "common.h"
 #include "dev-ap9x-pci.h"
 #include "dev-eth.h"
 #include "dev-gpio-buttons.h"
@@ -23,35 +25,44 @@
 #include "dev-usb.h"
 #include "machtypes.h"

-#define WNR2200_GPIO_LED_LAN2_AMBER0
-#define WNR2200_GPIO_LED_LAN4_AMBER1
-#define WNR2200_GPIO_LED_WPS5
-#define WNR2200_GPIO_LED_WAN_GREEN7
-#define WNR2200_GPIO_LED_USB8
-#define WNR2200_GPIO_LED_LAN3_AMBER11
-#define WNR2200_GPIO_LED_WAN_AMBER12
-#define WNR2200_GPIO_LED_LAN1_GREEN13
-#define WNR2200_GPIO_LED_LAN2_GREEN14
-#define WNR2200_GPIO_LED_LAN3_GREEN15
-#define WNR2200_GPIO_LED_LAN4_GREEN16
-#define WNR2200_GPIO_LED_PWR_AMBER21
-#define WNR2200_GPIO_LED_PWR_GREEN22
-
-#define WNR2200_GPIO_USB_POWER24
-
-#define WNR2200_KEYS_POLL_INTERVAL20 /* msecs */
-#define WNR2200_KEYS_DEBOUNCE_INTERVAL(3 * WNR2200_KEYS_POLL_INTERVAL)
-
-#define WNR2200_MAC0_OFFSET0
-#define WNR2200_MAC1_OFFSET6
-#define WNR2200_PCIE_CALDATA_OFFSET0x1000
+//AR9287 GPIO LED
+#define WNR2200_GPIO_LED_WLAN0
+#define WNR2200_GPIO_LED_PWR_AMBER1
+#define WNR2200_GPIO_LED_PWR_GREEN2
+#define WNR2200_GPIO_USB_5V4
+//AR9287 GPIO BUTTON
+#define WNR2200_GPIO_BUTTON_WIFI3
+#define WNR2200_GPIO_BUTTON_WPS5
+#define WNR2200_GPIO_BUTTON_RESET6
+
+//AR7241
+#define WNR2200_GPIO_LED_WPS7
+#define WNR2200_GPIO_LED_USB8
+
+#define WNR2200_GPIO_LED_LAN1_AMBER6
+#define WNR2200_GPIO_LED_LAN2_AMBER0
+#define WNR2200_GPIO_LED_LAN4_AMBER1
+#define WNR2200_GPIO_LED_LAN3_AMBER11
+#define WNR2200_GPIO_LED_WAN_AMBER12
+
+#define WNR2200_MAC0_OFFSET0
+#define WNR2200_MAC1_OFFSET6
+#define WNR2200_PCIE_CALDATA_OFFSET0x1000

 static struct gpio_led wnr2200_leds_gpio[] __initdata = {
 {
+.name= "netgear:amber:lan1",
+.gpio= WNR2200_GPIO_LED_LAN1_AMBER,
+.active_low= 1,
+}, {
 .name= "netgear:amber:lan2",
 .gpio= WNR2200_GPIO_LED_LAN2_AMBER,
 .active_low= 1,
 }, {
+.name= "netgear:amber:lan3",
+.gpio= WNR2200_GPIO_LED_LAN3_AMBER,
+.active_low= 1,
+}, {
 .name= "netgear:amber:lan4",
 .gpio= WNR2200_GPIO_LED_LAN4_AMBER,
 .active_low= 1,
@@ -60,45 +71,13 @@ static struct gpio_led wnr2200_leds_gpio[] __initdata = {
 .gpio= WNR2200_GPIO_LED_WPS,
 .active_low= 1,
 }, {
-.name= "netgear:green:wan",
-.gpio= WNR2200_GPIO_LED_WAN_GREEN,
-.active_low= 1,
-}, {
 .name= "netgear:green:usb",
 .gpio= WNR2200_GPIO_LED_USB,
 .active_low= 1,
 }, {
-.name= "netgear:amber:lan3",
-.gpio= WNR2200_GPIO_LED_LAN3_AMBER,
-.active_low= 1,
-}, {
 .name= "netgear:amber:wan",
 .gpio= WNR2200_GPIO_LED_WAN_AMBER,
 .active_low= 1,
-}, {
-.name= "netgear:green:lan1",
-.gpio= WNR2200_GPIO_LED_LAN1_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:green:lan2",
-.gpio= WNR2200_GPIO_LED_LAN2_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:green:lan3",
-.gpio= WNR2200_GPIO_LED_LAN3_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:green:lan4",
-.gpio= WNR2200_GPIO_LED_LAN4_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:amber:power",
-.gpio= WNR2200_GPIO_LED_PWR_AMBER,
-.active_low= 1,
-}, {
-.name= "netgear:green:power",
-.gpio= WNR2200_GPIO_LED_PWR_GREEN,
-.active_low= 1,
 }
 };

@@ -106,6 +85,8 @@ static void __init wnr2200_setup(void)
 {
 u8 *art = (u8 *) KSEG1ADDR(0x1fff);

+ath79_gpio_function_setup(AR724X_GPIO_FUNC_JTAG_DISABLE, 0);
+
 ath79_register_mdio(0, 0x0);

 ath79_init_mac(ath79_eth0_data.mac_addr, art+WNR2200_MAC0_OFFSET, 0);
@@ -121,15 +102,16 @@ static void __init wnr2200_setup(void)
 ath79_register_eth(1);

 ath79_register_m25p80(NULL);
-ap91_pci_init(art + WNR2200_PCIE_CALDATA_OFFSET, NULL);
-
+ap91_pci_init(art + WNR2200_PCIE_CALDATA_OFFSET

Re: [OpenWrt-Devel] [PATCH] base-files: remove a 'not found' error message during system boot

[Stam, Michel [FINT]]

Hello Jo,

I was not aware of this option, must have overlooked it. I will fix the
patch and resubmit it.

Kind regards,

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

[OpenWrt-Devel] [PATCH] ar71xx: fix netgear wnr2200 leds gpio and usb power

[郭涛]

This patch fix the wnr2200 leds gpio, every lan led works now;
fix usb power, usb device can works now;
fix ar9287 led

Signed-off-by: Tao Guo 
---
 .../ar71xx/files/arch/mips/ath79/mach-wnr2200.c| 100 +
 1 file changed, 41 insertions(+), 59 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
index bf7f9ee..d06a2f4 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
@@ -14,7 +14,9 @@
 #include 

 #include 
+#include 

+#include "common.h"
 #include "dev-ap9x-pci.h"
 #include "dev-eth.h"
 #include "dev-gpio-buttons.h"
@@ -23,35 +25,44 @@
 #include "dev-usb.h"
 #include "machtypes.h"

-#define WNR2200_GPIO_LED_LAN2_AMBER0
-#define WNR2200_GPIO_LED_LAN4_AMBER1
-#define WNR2200_GPIO_LED_WPS5
-#define WNR2200_GPIO_LED_WAN_GREEN7
-#define WNR2200_GPIO_LED_USB8
-#define WNR2200_GPIO_LED_LAN3_AMBER11
-#define WNR2200_GPIO_LED_WAN_AMBER12
-#define WNR2200_GPIO_LED_LAN1_GREEN13
-#define WNR2200_GPIO_LED_LAN2_GREEN14
-#define WNR2200_GPIO_LED_LAN3_GREEN15
-#define WNR2200_GPIO_LED_LAN4_GREEN16
-#define WNR2200_GPIO_LED_PWR_AMBER21
-#define WNR2200_GPIO_LED_PWR_GREEN22
-
-#define WNR2200_GPIO_USB_POWER24
-
-#define WNR2200_KEYS_POLL_INTERVAL20 /* msecs */
-#define WNR2200_KEYS_DEBOUNCE_INTERVAL(3 * WNR2200_KEYS_POLL_INTERVAL)
-
-#define WNR2200_MAC0_OFFSET0
-#define WNR2200_MAC1_OFFSET6
-#define WNR2200_PCIE_CALDATA_OFFSET0x1000
+//AR9287 GPIO LED
+#define WNR2200_GPIO_LED_WLAN0
+#define WNR2200_GPIO_LED_PWR_AMBER1
+#define WNR2200_GPIO_LED_PWR_GREEN2
+#define WNR2200_GPIO_USB_5V4
+//AR9287 GPIO BUTTON
+#define WNR2200_GPIO_BUTTON_WIFI3
+#define WNR2200_GPIO_BUTTON_WPS5
+#define WNR2200_GPIO_BUTTON_RESET6
+
+//AR7241
+#define WNR2200_GPIO_LED_WPS7
+#define WNR2200_GPIO_LED_USB8
+
+#define WNR2200_GPIO_LED_LAN1_AMBER6
+#define WNR2200_GPIO_LED_LAN2_AMBER0
+#define WNR2200_GPIO_LED_LAN4_AMBER1
+#define WNR2200_GPIO_LED_LAN3_AMBER11
+#define WNR2200_GPIO_LED_WAN_AMBER12
+
+#define WNR2200_MAC0_OFFSET0
+#define WNR2200_MAC1_OFFSET6
+#define WNR2200_PCIE_CALDATA_OFFSET0x1000

 static struct gpio_led wnr2200_leds_gpio[] __initdata = {
 {
+.name= "netgear:amber:lan1",
+.gpio= WNR2200_GPIO_LED_LAN1_AMBER,
+.active_low= 1,
+}, {
 .name= "netgear:amber:lan2",
 .gpio= WNR2200_GPIO_LED_LAN2_AMBER,
 .active_low= 1,
 }, {
+.name= "netgear:amber:lan3",
+.gpio= WNR2200_GPIO_LED_LAN3_AMBER,
+.active_low= 1,
+}, {
 .name= "netgear:amber:lan4",
 .gpio= WNR2200_GPIO_LED_LAN4_AMBER,
 .active_low= 1,
@@ -60,45 +71,13 @@ static struct gpio_led wnr2200_leds_gpio[] __initdata = {
 .gpio= WNR2200_GPIO_LED_WPS,
 .active_low= 1,
 }, {
-.name= "netgear:green:wan",
-.gpio= WNR2200_GPIO_LED_WAN_GREEN,
-.active_low= 1,
-}, {
 .name= "netgear:green:usb",
 .gpio= WNR2200_GPIO_LED_USB,
 .active_low= 1,
 }, {
-.name= "netgear:amber:lan3",
-.gpio= WNR2200_GPIO_LED_LAN3_AMBER,
-.active_low= 1,
-}, {
 .name= "netgear:amber:wan",
 .gpio= WNR2200_GPIO_LED_WAN_AMBER,
 .active_low= 1,
-}, {
-.name= "netgear:green:lan1",
-.gpio= WNR2200_GPIO_LED_LAN1_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:green:lan2",
-.gpio= WNR2200_GPIO_LED_LAN2_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:green:lan3",
-.gpio= WNR2200_GPIO_LED_LAN3_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:green:lan4",
-.gpio= WNR2200_GPIO_LED_LAN4_GREEN,
-.active_low= 1,
-}, {
-.name= "netgear:amber:power",
-.gpio= WNR2200_GPIO_LED_PWR_AMBER,
-.active_low= 1,
-}, {
-.name= "netgear:green:power",
-.gpio= WNR2200_GPIO_LED_PWR_GREEN,
-.active_low= 1,
 }
 };

@@ -106,6 +85,8 @@ static void __init wnr2200_setup(void)
 {
 u8 *art = (u8 *) KSEG1ADDR(0x1fff);

+ath79_gpio_function_setup(AR724X_GPIO_FUNC_JTAG_DISABLE, 0);
+
 ath79_register_mdio(0, 0x0);

 ath79_init_mac(ath79_eth0_data.mac_addr, art+WNR2200_MAC0_OFFSET, 0);
@@ -121,15 +102,16 @@ static void __init wnr2200_setup(void)
 ath79_register_eth(1);

 ath79_register_m25p80(NU

[OpenWrt-Devel] [PATCH v2] base-files: remove a 'not found' error message during system boot

[Michel Stam]

During boot, a not found message is displayed for systems which do
not have uci 'network.globals.ula_prefix' defined in
/etc/config/network. The error message itself is not used and can
be ignored.

Signed-off-by: Michel Stam 
---
 package/base-files/files/etc/uci-defaults/12_network-generate-ula | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/etc/uci-defaults/12_network-generate-ula 
b/package/base-files/files/etc/uci-defaults/12_network-generate-ula
index 56b7eb3..8871427 100644
--- a/package/base-files/files/etc/uci-defaults/12_network-generate-ula
+++ b/package/base-files/files/etc/uci-defaults/12_network-generate-ula
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-[ "$(uci get network.globals.ula_prefix)" != "auto" ] && exit 0
+[ "$(uci -q get network.globals.ula_prefix)" != "auto" ] && exit 0
 
 r1=$(dd if=/dev/urandom bs=1 count=1 |hexdump -e '1/1 "%02x"')
 r2=$(dd if=/dev/urandom bs=2 count=1 |hexdump -e '2/1 "%02x"')
-- 
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository

[Christian Schoenebeck]

Hi,

we got a new ticket inside OpenWrt Ticket #18018 with problems inside LuCI app.
This is normally not an OpenWrt ticket it's a LuCI ticket, but the user don't 
know.

If the user try to post the ticket at LuCI trac it takes weeks before the 
ticket 
is reported by LuciTrac to the mailing lists. So for a me as an "external" 
developer 
there is no chance to help quick. 
LuCi trac is also no good choice to send patches or possibly new functionality.
LuCI trac has problems to accept file attachments when creating a new ticket.
LuCI trac gives no chance to correct/edit a ticket or append a comment if you 
just create it.
>From my point of view LuCi trac is more then awful including used CHAPTCHA.

Sending patches or new functionality to luci mailing list is also not a choice 
because there is no guarantee that the code is implemented short term.

My idea is to move code of LuCI applications like tinyproxy, samba, hd-idle, 
ddns-scripts, .
to OpenWrt/packages as samba/samba-luci, tinyproxy/tinyproxy-luci or 
ddns-scripts/ddns-scripts-luci.
The mwan3 package already doing this. 

I think this is the best way, because openwrt/packages are moving fast forward 
and needed changes to the corresponding LuCI apps needs to be in sync.

My port/move for luci-app-ddns is ready for take off.

What do you think ?

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

[OpenWrt-Devel] Please could somebody implement this short term [OpenWrt] #18018: luci-app-ddns is missing the event interface option

[Christian Schoenebeck]

Am 03.10.2014 um 09:31 schrieb OpenWrt:
> #18018: luci-app-ddns is missing the event interface option
> -+---
>   Reporter:  techstep@…  |  Owner:  developers
>   Type:  defect  | Status:  new
>   Priority:  normal  |  Milestone:
>  Component:  packages|Version:  Barrier Breaker 14.07
> Resolution:  |   Keywords:  luci-app-ddns
> -+---
> 
> Comment (by chris5560):
> 
>  Attached patch can be used for luci-0.12 AND luci-trunk
>  I current luci-trunk is the same error.
>  It's an svn patch for luci svn
> 
>  Christian
> 
> --
> Ticket URL: 
> OpenWrt 
> Opensource Wireless Router Technology
> 
Hi,
please could somebody implement this patch short term as backport to LuCI 0.12 
and replace it inside BB14.07 packages.

Many thanks

Christian

Index: applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua
===
--- applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua	(Revision 10533)
+++ applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua	(Arbeitskopie)
@@ -26,6 +26,10 @@
 
 s:option(Flag, "enabled", translate("Enable"))
 
+interface = s:option(ListValue, "interface", translate("Event interface"), translate("On which interface up should start the ddns script process."))
+luci.tools.webadmin.cbi_add_networks(interface)
+interface.default = "wan"
+
 svc = s:option(ListValue, "service_name", translate("Service"))
 svc.rmempty = false
 svc.default = "dyndns.org"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Please could somebody implement this short term [OpenWrt] #18018: luci-app-ddns is missing the event interface option

[Jo-Philipp Wich]

Whats the meaning of this option?

The description text is awful and since I do not know what it is
supposed to do I cannot write a proper one.

Also a signed-off-by would be good.

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

[OpenWrt-Devel] [PATCH] brcm63xx: fix wrong fixups pointer

[Álvaro Fernández Rojas]

Signed-off-by: Álvaro Fernández Rojas 
---
diff --git a/target/linux/brcm63xx/patches-3.14/505-board_spw500v.patch 
b/target/linux/brcm63xx/patches-3.14/505-board_spw500v.patch
index e2d36e7..f326a9e 100644
--- a/target/linux/brcm63xx/patches-3.14/505-board_spw500v.patch
+++ b/target/linux/brcm63xx/patches-3.14/505-board_spw500v.patch
@@ -79,7 +79,7 @@
 +  .type   = SPROM_BCM4318,
 +  .pci_bus= 0,
 +  .pci_dev= 1,
-+  .board_fixups   = &spw500v_fixups,
++  .board_fixups   = spw500v_fixups,
 +  .num_board_fixups   = ARRAY_SIZE(spw500v_fixups),
 +  },
 +};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Please could somebody implement this short term [OpenWrt] #18018: luci-app-ddns is missing the event interface option

[Christian Schoenebeck]

Am 03.10.2014 um 12:24 schrieb Jo-Philipp Wich:
> Whats the meaning of this option?
> 
> The description text is awful and since I do not know what it is
> supposed to do I cannot write a proper one.
> 
> Also a signed-off-by would be good.
> 
> ~ Jow
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
Hi Jow,

The original code in luci-0.11 used for AA12.09 is your code.
The code inside luci-0.12 and luci-trunk was changed in 2013 by Manuel Munz 

What happened in the meanwhile with the code, I don't know.
I only copy 3 lines of code from 0.11 to 0.12.

The (re)attached patch, brings back the event interface to luci-app-ddns.
Without "option interface" set, ddns-scripts will never work.
Without setting the event interface, a user using LuCi WebUI has no chance 
to use Dynamic DNS without hack the config from console,
because the ddns-scripts behind it will not work.

Signed-off-by: Christian Schoenebeck 

---

Index: applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua
===
--- applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua   (Revision 10533)
+++ applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua   (Arbeitskopie)
@@ -26,6 +26,10 @@
 
 s:option(Flag, "enabled", translate("Enable"))
 
+interface = s:option(ListValue, "interface", translate("Event interface"), 
translate("On which interface up should start the ddns script process."))
+luci.tools.webadmin.cbi_add_networks(interface)
+interface.default = "wan"
+
 svc = s:option(ListValue, "service_name", translate("Service"))
 svc.rmempty = false
 svc.default = "dyndns.org"

Index: applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua
===
--- applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua	(Revision 10533)
+++ applications/luci-ddns/luasrc/model/cbi/ddns/ddns.lua	(Arbeitskopie)
@@ -26,6 +26,10 @@
 
 s:option(Flag, "enabled", translate("Enable"))
 
+interface = s:option(ListValue, "interface", translate("Event interface"), translate("On which interface up should start the ddns script process."))
+luci.tools.webadmin.cbi_add_networks(interface)
+interface.default = "wan"
+
 svc = s:option(ListValue, "service_name", translate("Service"))
 svc.rmempty = false
 svc.default = "dyndns.org"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [luci] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository

[Nikos Mavrogiannopoulos]

On Fri, Oct 3, 2014 at 11:32 AM, Christian Schoenebeck
 wrote:
> Hi,
> we got a new ticket inside OpenWrt Ticket #18018 with problems inside LuCI 
> app.
> This is normally not an OpenWrt ticket it's a LuCI ticket, but the user don't 
> know.
> If the user try to post the ticket at LuCI trac it takes weeks before the 
> ticket
> is reported by LuciTrac to the mailing lists. So for a me as an "external" 
> developer
> there is no chance to help quick.
[...]
> My idea is to move code of LuCI applications like tinyproxy, samba, hd-idle, 
> ddns-scripts, .
> to OpenWrt/packages as samba/samba-luci, tinyproxy/tinyproxy-luci or 
> ddns-scripts/ddns-scripts-luci.
> The mwan3 package already doing this.
>
> I think this is the best way, because openwrt/packages are moving fast forward
> and needed changes to the corresponding LuCI apps needs to be in sync.
> What do you think ?

I concur, my impression with the luci part of the project is that it
is unable to cope with any changes/new functionality proposal. It
would be nice to respin it as part of packages.

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

Re: [OpenWrt-Devel] why is 'wan' port missing in luci switch vlan setup page for Netgear WNR2200 ?

[Urs Rau (UK)]

Hi Jo-Philipp,

On 26 Sep 2014, at 09:55, Jo-Philipp Wich 
mailto:j...@openwrt.org>> wrote:

Hi.

The wan port is likely a dedicated, non-switch interface (e.g. eth1) on
this model. If you want to declare VLANs on it then simply create a new
interface using eth1.Y as manual physical ifname where Y denotes the
desired VLAN id.

~ Jow

yes, I think you are right.

eth0 is the yellow wan port

and eth1 is the 4 port switch on this hardware

but now I have a problem, how do i get tagged VLAN  traffic coming in on 
eth0.96 eth0.128 eth0.144 eth0.160 eth0.168 to ‘connect’ or ‘forward’ to the 
relevant eth1.VLANID ? on other models the wan port is part of the same switch 
and I can tick the ‘cpu’ port in luci to ‘transport’ or ‘forward’ the right wan 
VLAn with the right LAN port 1 - 4.

How can I do this on this hardware which has one wan port that is not part of 
the switch and for lan ports that are part of the switch that luci shows under 
the ‘switch’ page?

or do I have to ‘forget’ about using the ‘wan’ port and work with the lan ports 
1 - 4 only?

—
Urs Rau


Operation Mobilisation (OM) - a company limited by guarantee - The Quinta, 
Weston Rhyn, Oswestry, SY10 7LT, United Kingdom
Company reg no: 2564320 (England & Wales) - Charity reg. no: 1008196 (England & 
Wales) - SC040988 (Scotland)
Web: http://www.uk.om.org

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

Re: [OpenWrt-Devel] why is 'wan' port missing in luci switch vlan setup page for Netgear WNR2200 ?

[David Lang]

On Fri, 3 Oct 2014, Urs Rau (UK) wrote:


Hi Jo-Philipp,

On 26 Sep 2014, at 09:55, Jo-Philipp Wich 
mailto:j...@openwrt.org>> wrote:

Hi.

The wan port is likely a dedicated, non-switch interface (e.g. eth1) on
this model. If you want to declare VLANs on it then simply create a new
interface using eth1.Y as manual physical ifname where Y denotes the
desired VLAN id.

~ Jow

yes, I think you are right.

eth0 is the yellow wan port

and eth1 is the 4 port switch on this hardware

but now I have a problem, how do i get tagged VLAN  traffic coming in on 
eth0.96 eth0.128 eth0.144 eth0.160 eth0.168 to ‘connect’ or ‘forward’ to the 
relevant eth1.VLANID ? on other models the wan port is part of the same switch 
and I can tick the ‘cpu’ port in luci to ‘transport’ or ‘forward’ the right wan 
VLAn with the right LAN port 1 - 4.

How can I do this on this hardware which has one wan port that is not part of 
the switch and for lan ports that are part of the switch that luci shows under 
the ‘switch’ page?

or do I have to ‘forget’ about using the ‘wan’ port and work with the lan ports 
1 - 4 only?


you bridge between the eth0.x and eth1.x interfaces (where x is the VLAN)

keep in mind that since this traffic is going through the kernel to get from one 
side to the other instead of just through the switch, it is going to be slower.


David Lang___
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] Please could somebody implement this short term [OpenWrt] #18018: luci-app-ddns is missing the event interface option

[Jo-Philipp Wich]

Hi,

thanks for the patch. however the description still looks grammatically
wrong: "On which interface up should start the ddns script process."

Maybe it can be better written as "Trigger DDNS update when this
interface is started"

Ideas?

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

Re: [OpenWrt-Devel] Please could somebody implement this short term [OpenWrt] #18018: luci-app-ddns is missing the event interface option

[Christian Schoenebeck]

Am 03.10.2014 um 14:53 schrieb Jo-Philipp Wich:
> Hi,
> 
> thanks for the patch. however the description still looks grammatically
> wrong: "On which interface up should start the ddns script process."
> 
> Maybe it can be better written as "Trigger DDNS update when this
> interface is started"
> 
> Ideas?
> 
> ~ Jow
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
Hi,

you are right, but it's not "my English", the three lines are simply copied 
from luci-0.11 branch,
so hopefully all existing LuCI translations will work without changes.
It's a quick patch to make the system running for bb14.07 users.

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

Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications to work with procd

[Gert Doering]

Hi,

On Thu, Oct 02, 2014 at 02:56:18PM +0200, Michel Stam wrote:
> The problem was caused by procd not opening /dev/tty* (which ever was 
> specified in
> /etc/inittab), causing /proc/PID/fd to point to /console instead. 
> /dev/console is a
> non-controlling tty (CTTY), and cannot be used as one, which is exactly what 
> curses
> applications want. Since this is very likely to cause problems with other 
> programs,
> procd now opens /dev/tty? when the ID field of the inittab assigns one, and 
> forces
> this to be a CTTY.

I won't claim to understand the OpenWRT intricacies here, so take this with
a grain of salt.

In traditional unix systems, setting up a tty and acquiring a controlling
tty is getty's job, and not that of the init system - and init should not
start interactive programs (or "possibly interactive programs") from 
/etc/inittab.

Changing this is fairly invasive into the way the system works and what
programs can expect regarding signal delivery etc. - like, someone pressing
ctrl-c on a tty, and a background process being started on that tty will
get a SIGINT (while it normally wouldn't).

Genuinely curious: can you explain a bit better in which cases this change
would be needed and/or beneficial?

thanks,

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpnKgLckH1oR.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH][BB, toolchain] Fix broken implementation of NOEXECSTACK flag for MIPS architectures for gcc-linaro-4.8

[Andrew McDonnell]

This patch ensures that libgcc_s.so properly honours the NOEXECSTACK flag
for MIPS builds, when gcc-linaro-4.8 is the chosen C compiler.

Signed-off-by: Andrew McDonnell 

---
Extended Summary: NOEXECSTACK is a security hardening feature of Linux that
prevents execution of arbitrary code for some classes of buffer overflow.
When the binaries and libraries in a firmware image are scanned with the
checksec tool [1,2] on x86 OpenWRT firmware all have the marking, but in MIPS
firmware very few have the marking.

To cut a long story short, libgcc_s.so is built in a way that causes it to
have an executable stack, and because most other binaries and libraries are
linked to this library, they in turn also have an executable stack.  The fix
for this is a backport patch against the development of gcc. [3,4]

[1] https://github.com/slimm609/checksec.sh
[2] http://www.trapkit.de/tools/checksec.html
[3] http://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart
[4] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02430.html 

This is probably required against gc 4.6 and gcc 4.8 as well.

 .../4.8-linaro/930-fix-mips-noexecstack.patch  | 124 +
 1 file changed, 124 insertions(+)
 create mode 100644 
toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch

diff --git a/toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch 
b/toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch
new file mode 100644
index 000..81deda6
--- /dev/null
+++ b/toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch
@@ -0,0 +1,124 @@
+From da45b3fde60095756f5f6030f6012c23a3d34429 Mon Sep 17 00:00:00 2001
+From: Andrew McDonnell 
+Date: Fri, 3 Oct 2014 19:09:00 +0930
+Subject: Add .note.GNU-stack section
+
+See http://lists.busybox.net/pipermail/uclibc/2014-October/048671.html
+Below copied from https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02430.html
+
+Re: [Patch, MIPS] Add .note.GNU-stack section
+
+From: Steve Ellcey 
+
+On Wed, 2014-09-10 at 10:15 -0700, Eric Christopher wrote:
+>
+>
+> On Wed, Sep 10, 2014 at 9:27 AM,  wrote:
+
+> This works except you did not update the assembly files in
+> libgcc or glibc. We (Cavium) have the same patch in our tree
+> for a few released versions.
+
+> Mind just checking yours in then Andrew?
+
+> Thanks!
+> -eric
+
+I talked to Andrew about what files he changed in GCC and created and
+tested this new patch.  Andrew also mentioned changing some assembly
+files in glibc but I don't see any use of '.section .note.GNU-stack' in
+any assembly files in glibc (for any platform) so I wasn't planning on
+creating a glibc to add them to mips glibc assembly language files.
+
+OK to check in this patch?
+
+Steve Ellcey
+sell...@mips.com
+
+
+
+2014-09-26  Steve Ellcey  
+---
+ gcc/config/mips/mips.c  | 3 +++
+ libgcc/config/mips/crti.S   | 4 
+ libgcc/config/mips/crtn.S   | 3 +++
+ libgcc/config/mips/mips16.S | 4 
+ libgcc/config/mips/vr4120-div.S | 4 
+ 5 files changed, 18 insertions(+)
+
+diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
+index 41c5d6b..33d9793 100644
+--- a/gcc/config/mips/mips.c
 b/gcc/config/mips/mips.c
+@@ -18223,6 +18223,9 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
+ #undef TARGET_VECTORIZE_VEC_PERM_CONST_OK
+ #define TARGET_VECTORIZE_VEC_PERM_CONST_OK mips_vectorize_vec_perm_const_ok
+ 
++#undef TARGET_ASM_FILE_END
++#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
++
+ struct gcc_target targetm = TARGET_INITIALIZER;
+ 
+ #include "gt-mips.h"
+diff --git a/libgcc/config/mips/crti.S b/libgcc/config/mips/crti.S
+index c7418db..e5f2762 100644
+--- a/libgcc/config/mips/crti.S
 b/libgcc/config/mips/crti.S
+@@ -21,6 +21,10 @@ a copy of the GCC Runtime Library Exception along with this 
program;
+ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+ .  */
+ 
++
++/* An executable stack is *not* required for these functions.  */
++  .section .note.GNU-stack,"",%progbits
++
+ /* 4 slots for argument spill area.  1 for cpreturn, 1 for stack.
+Return spill offset of 40 and 20.  Aligned to 16 bytes for n32.  */
+ 
+diff --git a/libgcc/config/mips/crtn.S b/libgcc/config/mips/crtn.S
+index 59d1a90..5cc03bf 100644
+--- a/libgcc/config/mips/crtn.S
 b/libgcc/config/mips/crtn.S
+@@ -21,6 +21,9 @@ a copy of the GCC Runtime Library Exception along with this 
program;
+ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+ .  */
+ 
++/* An executable stack is *not* required for these functions.  */
++.section .note.GNU-stack,"",%progbits
++
+ /* 4 slots for argument spill area.  1 for cpreturn, 1 for stack.
+Return spill offset of 40 and 20.  Aligned to 16 bytes for n32.  */
+ 
+diff --git a/libgcc/config/mips/mips16.S b/libgcc/config/mips/mips16.S
+index ab3a794..4ded5da 100644
+--- a/libgcc/config/mips/mips16.S
 b/libgcc/config/

[OpenWrt-Devel] [PATCH][toolchain] Fix broken implementation of NOEXECSTACK flag for MIPS architectures for gcc-linaro-4.8

[Andrew McDonnell]

This patch ensures that libgcc_s.so properly honours the NOEXECSTACK flag
for MIPS builds, when gcc-linaro-4.8 is the chosen C compiler.

Signed-off-by: Andrew McDonnell 

---
Extended Summary: NOEXECSTACK is a security hardening feature of Linux that
prevents execution of arbitrary code for some classes of buffer overflow.
When the binaries and libraries in a firmware image are scanned with the
checksec tool [1,2] on x86 OpenWRT firmware all have the marking, but in MIPS
firmware very few have the marking.

To cut a long story short, libgcc_s.so is built in a way that causes it to
have an executable stack, and because most other binaries and libraries are
linked to this library, they in turn also have an executable stack.  The fix
for this is a backport patch against the development of gcc. [3,4]

[1] https://github.com/slimm609/checksec.sh
[2] http://www.trapkit.de/tools/checksec.html
[3] http://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart
[4] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02430.html 

This is probably required against gc 4.6 and gcc 4.8 as well.

 .../4.8-linaro/930-fix-mips-noexecstack.patch  | 124 +
 1 file changed, 124 insertions(+)
 create mode 100644 
toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch

diff --git a/toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch 
b/toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch
new file mode 100644
index 000..81deda6
--- /dev/null
+++ b/toolchain/gcc/patches/4.8-linaro/930-fix-mips-noexecstack.patch
@@ -0,0 +1,124 @@
+From da45b3fde60095756f5f6030f6012c23a3d34429 Mon Sep 17 00:00:00 2001
+From: Andrew McDonnell 
+Date: Fri, 3 Oct 2014 19:09:00 +0930
+Subject: Add .note.GNU-stack section
+
+See http://lists.busybox.net/pipermail/uclibc/2014-October/048671.html
+Below copied from https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02430.html
+
+Re: [Patch, MIPS] Add .note.GNU-stack section
+
+From: Steve Ellcey 
+
+On Wed, 2014-09-10 at 10:15 -0700, Eric Christopher wrote:
+>
+>
+> On Wed, Sep 10, 2014 at 9:27 AM,  wrote:
+
+> This works except you did not update the assembly files in
+> libgcc or glibc. We (Cavium) have the same patch in our tree
+> for a few released versions.
+
+> Mind just checking yours in then Andrew?
+
+> Thanks!
+> -eric
+
+I talked to Andrew about what files he changed in GCC and created and
+tested this new patch.  Andrew also mentioned changing some assembly
+files in glibc but I don't see any use of '.section .note.GNU-stack' in
+any assembly files in glibc (for any platform) so I wasn't planning on
+creating a glibc to add them to mips glibc assembly language files.
+
+OK to check in this patch?
+
+Steve Ellcey
+sell...@mips.com
+
+
+
+2014-09-26  Steve Ellcey  
+---
+ gcc/config/mips/mips.c  | 3 +++
+ libgcc/config/mips/crti.S   | 4 
+ libgcc/config/mips/crtn.S   | 3 +++
+ libgcc/config/mips/mips16.S | 4 
+ libgcc/config/mips/vr4120-div.S | 4 
+ 5 files changed, 18 insertions(+)
+
+diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
+index 41c5d6b..33d9793 100644
+--- a/gcc/config/mips/mips.c
 b/gcc/config/mips/mips.c
+@@ -18223,6 +18223,9 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
+ #undef TARGET_VECTORIZE_VEC_PERM_CONST_OK
+ #define TARGET_VECTORIZE_VEC_PERM_CONST_OK mips_vectorize_vec_perm_const_ok
+ 
++#undef TARGET_ASM_FILE_END
++#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
++
+ struct gcc_target targetm = TARGET_INITIALIZER;
+ 
+ #include "gt-mips.h"
+diff --git a/libgcc/config/mips/crti.S b/libgcc/config/mips/crti.S
+index c7418db..e5f2762 100644
+--- a/libgcc/config/mips/crti.S
 b/libgcc/config/mips/crti.S
+@@ -21,6 +21,10 @@ a copy of the GCC Runtime Library Exception along with this 
program;
+ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+ .  */
+ 
++
++/* An executable stack is *not* required for these functions.  */
++  .section .note.GNU-stack,"",%progbits
++
+ /* 4 slots for argument spill area.  1 for cpreturn, 1 for stack.
+Return spill offset of 40 and 20.  Aligned to 16 bytes for n32.  */
+ 
+diff --git a/libgcc/config/mips/crtn.S b/libgcc/config/mips/crtn.S
+index 59d1a90..5cc03bf 100644
+--- a/libgcc/config/mips/crtn.S
 b/libgcc/config/mips/crtn.S
+@@ -21,6 +21,9 @@ a copy of the GCC Runtime Library Exception along with this 
program;
+ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+ .  */
+ 
++/* An executable stack is *not* required for these functions.  */
++.section .note.GNU-stack,"",%progbits
++
+ /* 4 slots for argument spill area.  1 for cpreturn, 1 for stack.
+Return spill offset of 40 and 20.  Aligned to 16 bytes for n32.  */
+ 
+diff --git a/libgcc/config/mips/mips16.S b/libgcc/config/mips/mips16.S
+index ab3a794..4ded5da 100644
+--- a/libgcc/config/mips/mips16.S
 b/libgcc/config/

Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications to work with procd

[Stam, Michel [FINT]]

Hello Gert,

Good question.

What we discovered during an upgrade of our OpenWRT distribution (from a
fairly old one, I cannot exactly recall the version, I do recall it was
running kernel 2.6.22), was that suddenly our curses application did not
start anymore. And yes, for historical reasons, it was executed from the
inittab, no argument there.

I was looking into the reason and typing an answer to you, but I have to
look a little better as to the why. If you don't mind, I will get back
to you on Monday.

Kind regards,

Michel Stam

-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de] 
Sent: Friday, October 03, 2014 16:16 PM
To: Stam, Michel [FINT]
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications
to work with procd

Hi,

On Thu, Oct 02, 2014 at 02:56:18PM +0200, Michel Stam wrote:
> The problem was caused by procd not opening /dev/tty* (which ever was 
> specified in /etc/inittab), causing /proc/PID/fd to point to /console 
> instead. /dev/console is a non-controlling tty (CTTY), and cannot be 
> used as one, which is exactly what curses applications want. Since 
> this is very likely to cause problems with other programs, procd now 
> opens /dev/tty? when the ID field of the inittab assigns one, and
forces this to be a CTTY.

I won't claim to understand the OpenWRT intricacies here, so take this
with a grain of salt.

In traditional unix systems, setting up a tty and acquiring a
controlling tty is getty's job, and not that of the init system - and
init should not start interactive programs (or "possibly interactive
programs") from /etc/inittab.

Changing this is fairly invasive into the way the system works and what
programs can expect regarding signal delivery etc. - like, someone
pressing ctrl-c on a tty, and a background process being started on that
tty will get a SIGINT (while it normally wouldn't).

Genuinely curious: can you explain a bit better in which cases this
change would be needed and/or beneficial?

thanks,

gert
--
USENET is *not* the non-clickable part of WWW!
 
//www.muc.de/~gert/
Gert Doering - Munich, Germany
g...@greenie.muc.de
fax: +49-89-35655025
g...@net.informatik.tu-muenchen.de
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WAN bouncing at boot

[Weedy]

On Tue, Aug 12, 2014 at 10:05 AM, Bas Mevissen  wrote:
>
>
> On 08/09/2014 04:13 AM, Weedy wrote:
>> On Sun, Jul 27, 2014 at 3:31 PM, Weedy  wrote:
>>> Is there anything I can do to stop this? It started sometime in the
>>> last 6months of trunk.
>>> Right after this and couple minutes after boot my healing script fires
>>> and detects that WAN is broken and calls ifdown; sleep; ifup at which
>>> point I get an IP and keep it. But why it the WAN goinig up and down
>>> during boot?
>>>
>
> Difficult to help you without any information about the platform.
>
> You might go back in time and track down the change that caused the
> issue by bisection. Can take some time to execute, but is feasible when
> the problem is reproducible. Beware that when going back in time with
> the sources, you must force recompilation.

TP-Link 4300 on trunk. It only bounces at boot. I got 5 or 6
distcleans into it and it's just so disruptive. I would be nice to
have a hint.

Thu Oct  2 19:48:33 2014 kern.info kernel: [0.61] switch0:
Atheros AR8327 rev. 2 switch registered on ag71xx-mdio.0
Thu Oct  2 19:48:33 2014 kern.info kernel: [1.84] libphy:
ag71xx_mdio: probed
Thu Oct  2 19:48:33 2014 kern.info kernel: [2.39] ag71xx
ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd033,
driver=Atheros AR8216/AR8236/AR8316]
Thu Oct  2 19:48:33 2014 kern.info kernel: [2.40] eth0:
Atheros AG71xx at 0xb900, irq 4, mode:RGMII
Thu Oct  2 19:48:33 2014 kern.info kernel: [2.41] TCP: cubic registered
Thu Oct  2 19:48:33 2014 kern.info kernel: [2.41] NET:
Registered protocol family 17
Thu Oct  2 19:48:33 2014 kern.info kernel: [2.42] 8021q:
802.1Q VLAN Support v1.8
Thu Oct  2 19:48:33 2014 kern.info kernel: [2.43] VFS: Mounted
root (squashfs filesystem) readonly on device 31:2.
Thu Oct  2 19:48:33 2014 kern.info kernel: [2.44] Freeing
unused kernel memory: 284K (80329000 - 8037)
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.74] usbcore:
registered new interface driver usbfs
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.75] usbcore:
registered new interface driver hub
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.76] usbcore:
registered new device driver usb
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.77] ehci_hcd:
USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.77]
ehci-platform: EHCI generic platform driver
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.78]
ehci-platform ehci-platform: EHCI Host Controller
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.78]
ehci-platform ehci-platform: new USB bus registered, assigned bus
number 1
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.79]
ehci-platform ehci-platform: irq 3, io mem 0x1b00
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.82]
ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.82] hub 1-0:1.0:
USB hub found
Thu Oct  2 19:48:33 2014 kern.info kernel: [4.83] hub 1-0:1.0:
1 port detected
Thu Oct  2 19:48:33 2014 kern.info kernel: [5.33] usb 1-1: new
high-speed USB device number 2 using ehci-platform
Thu Oct  2 19:48:33 2014 kern.info kernel: [5.48] hub 1-1:1.0:
USB hub found
Thu Oct  2 19:48:33 2014 kern.info kernel: [5.48] hub 1-1:1.0:
4 ports detected
Thu Oct  2 19:48:33 2014 kern.info kernel: [6.41] eth0: link
up (1000Mbps/Full duplex)
Thu Oct  2 19:48:33 2014 kern.info kernel: [8.65] eth0: link down
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.35] NET:
Registered protocol family 10
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.37] ip6_tables:
(C) 2000-2006 Netfilter Core Team
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.41] u32 classifier
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.41] input
device check on
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.41] Actions configured
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.42]
Mirror/redirect action on
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.44] nf_conntrack
version 0.5.0 (1976 buckets, 7904 max)
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.47] Loading
modules backported from Linux version master-2014-09-26-0-g25e3efa
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.47] Backport
generated by backports.git backports-20140905-1-gde42785
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.49] ip_tables:
(C) 2000-2006 Netfilter Core Team
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.63] xt_time:
kernel timezone is -
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.66] cfg80211:
Calling CRDA to update world regulatory domain
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.66] cfg80211:
World regulatory domain updated:
Thu Oct  2 19:48:33 2014 kern.info kernel: [   10.67] cfg80211:
DFS Master region: unset
Thu Oct  2 19:48:33 2014 k

Re: [OpenWrt-Devel] [PATCH procd 2/8] Log startup/shutdown to console

[John Crispin]

stdout is already /dev/console i think and removing the messages on
shutdown also removes them in all other cases from the log.

should adding a single printf("%s", str); not work ?

On 02/10/2014 14:56, Michel Stam wrote:
> procd has the habit of logging startup/shutdown via rcS to syslog,
> which is pointless in case of a shutdown, and unlikely to be
> complete on a startup (as syslog is not running). Write to
> /dev/console instead.
> 
> Signed-off-by: Michel Stam  --- rcS.c | 10
> ++ 1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/rcS.c b/rcS.c index 4545621..e01fc49 100644 ---
> a/rcS.c +++ b/rcS.c @@ -18,10 +18,11 @@
> 
> #include  #include  +#include
>  #include  #include  #include
>  - +#include  #include  #include
>  #include  @@ -43,8 +44,9 @@ struct initd { 
> static void pipe_cb(struct ustream *s, int bytes) { char *newline,
> *str; -   int len; +  int len, console_fd;
> 
> + console_fd = open(_PATH_CONSOLE, O_WRONLY | O_NOCTTY |
> O_NONBLOCK); do { str = ustream_get_read_buf(s, NULL); if (!str) @@
> -52,11 +54,11 @@ static void pipe_cb(struct ustream *s, int bytes) 
> newline = strchr(str, '\n'); if (!newline) break; -   *newline = 0; 
> len = newline + 1 - str; -syslog(0, "%s", str); +
> write(console_fd, str, len); ustream_consume(s, len); } while (1); 
> + close(console_fd); }
> 
> static void q_initd_run(struct runqueue *q, struct runqueue_task
> *t)
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH procd 7/8] Show the shutdown sequence on the active virtual terminal

[John Crispin]

see inline

On 02/10/2014 14:56, Michel Stam wrote:
> procd by default writes to /dev/console. When rebooting, this means
> that the terminal on which the reboot sequence was started will not
> see what is going on. This patch fixes that by reopening stdin,
> stdout and stderr to /dev/tty0 upon reboot.
> 
> Also, due to (probably) pivot-root, /proc/1/fd shows 1-3 pointing
> to /console. This patch also fixes that.
> 
> Signed-off-by: Michel Stam  --- state.c | 13
> + 1 file changed, 13 insertions(+)
> 
> diff --git a/state.c b/state.c index e6c8712..2268de3 100644 ---
> a/state.c +++ b/state.c @@ -12,7 +12,9 @@ * GNU General Public
> License for more details. */
> 
> +#include  #include  +#include  
> #include  #include  #include  @@
> -37,6 +39,14 @@ enum { static int state = STATE_NONE; static int
> reboot_event;
> 
> +static void set_stdio( const char* tty ) +{ +freopen( tty, "r",
> stdin ); +freopen( tty, "w", stdout ); +  freopen( tty, "w", stderr
> ); +  fcntl(STDERR_FILENO, F_SETFL, fcntl(STDERR_FILENO, F_GETFL) |
> O_NONBLOCK); +} + static void state_enter(void) { char ubus_cmd[] =
> "/sbin/ubusd"; @@ -55,6 +65,7 @@ static void state_enter(void) 
> LOG("- ubus -\n"); procd_connect_ubus();
> 
> + set_stdio( "/dev/console" ); LOG("- init -\n"); service_init(); 
> service_start_early("ubus", ubus_cmd); @@ -71,6 +82,8 @@ static
> void state_enter(void) break;
> 
> case STATE_SHUTDOWN: +/* Redirect output to the current 
> virtual
> terminal for the users' benefit */ +  set_stdio( "/dev/tty0" );

tty0 is a virtual console on a desktop. routers don't have a tty0.
this would break all the routers



> LOG("- shutdown -\n"); procd_inittab_run("shutdown"); sync();
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing 'noexecstack' in uClibc MIPS builds

[Catalin Patulea]

On Wed, Oct 1, 2014 at 6:42 PM, Andrew McDonnell
 wrote:
> It seems that OpenWRT sets the relevant flag to require uClibc to build with
> NOEXECSTACK set. This is good.  (For one introduction to NOEXECSTACK, see
> http://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart )
Does anything actually enforce NX on MIPS?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing 'noexecstack' in uClibc MIPS builds

[Felix Fietkau]

On 2014-10-03 19:14, Catalin Patulea wrote:
> On Wed, Oct 1, 2014 at 6:42 PM, Andrew McDonnell
>  wrote:
>> It seems that OpenWRT sets the relevant flag to require uClibc to build with
>> NOEXECSTACK set. This is good.  (For one introduction to NOEXECSTACK, see
>> http://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart )
> Does anything actually enforce NX on MIPS?
There are MIPS CPUs that support it, but my guess is that most of our
MIPS targets don't have any hardware support for it.

- Felix
___
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: remove the deluge of driver messages during bootup

[John Crispin]

On 02/10/2014 15:21, Michel Stam wrote:
> Early during bootup, kmodloader is started which loads the drivers
> in /etc/modules.d. Unfortunately at this time the system script has
> not run yet, which is supposed to set the console log level.
> Having the S10system script moved to an earlier time is not an
> option, as this in turn will not work because the system script
> will try to register itself with ubusd, which is not running
> either. This only happens after S12log is run.

we actually want to see these messages.

procd is supposed to wait for ubusd which it apparently did not do, so i
just wrote a patch to fix this problem.

>
> As a quick fix, temporarily show only errors and more severe
> messages. S10system will quickly fix that shortly after,
> at least the bootup is more sane (and readable).
>
> Signed-off-by: Michel Stam 
> ---
>  package/base-files/files/etc/init.d/boot | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/package/base-files/files/etc/init.d/boot 
> b/package/base-files/files/etc/init.d/boot
> index f10db13..9223807 100755
> --- a/package/base-files/files/etc/init.d/boot
> +++ b/package/base-files/files/etc/init.d/boot
> @@ -35,6 +35,9 @@ boot() {
>   grep -q debugfs /proc/filesystems && /bin/mount -o noatime -t debugfs 
> debugfs /sys/kernel/debug
>   [ "$FAILSAFE" = "true" ] && touch /tmp/.failsafe
>  
> + # Prevent module load messages from flooding the boot process; 'system' 
> service will fix this
> + /bin/dmesg -n 3
> +
>   /sbin/kmodloader
>  
>   # allow wifi modules time to settle
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: remove error from detect script

[John Crispin]

On 02/10/2014 15:28, Michel Stam wrote:
> Signed-off-by: Michel Stam 
> ---
>  package/kernel/mac80211/files/lib/wifi/mac80211.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh 
> b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> index a3b2199..2af4dc5 100644
> --- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> @@ -65,7 +65,7 @@ detect_mac80211() {
>   [ -n "$type" ] || break
>   devidx=$(($devidx + 1))
>   done
> - for dev in $(ls /sys/class/ieee80211); do
> + for dev in $(ls /sys/class/ieee80211 2>/dev/null); do
what error do you see ? if you see an error we should try to fix that
rather than supressing it


>   found=0
>   config_foreach check_mac80211_device wifi-device
>   [ "$found" -gt 0 ] && continue
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: remove error from detect script

[Jo-Philipp Wich]

Hi Michel, John.

>> -for dev in $(ls /sys/class/ieee80211); do
>> +for dev in $(ls /sys/class/ieee80211 2>/dev/null); do
> what error do you see ? if you see an error we should try to fix that
> rather than supressing it

I suppose the case when "wifi detect" is invoked but no phy exists on
the system (e.g. because the radio hardware is not installed - think USB).

In this case the entire /sys/class/ieee80211 is likely missing which
will cause "ls" to print a "No such file or directory" error.

Actually I do not really like that whole "for x in $(ls ...)" construct,
something like the following would save one fork and also not produce
errors:

for dev in /sys/class/ieee80211/*; do
if [ -h "$dev" ]; then
 # do something with ${dev##*/}
fi
done


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

Re: [OpenWrt-Devel] [PATCH] [package] dropbear: enable sha2-based hmac by default.

[Weedy]

On 27/09/14 01:29 PM, Alive wrote:
> On 27/09/2014 23:34, Weedy wrote:
>> I got bit by this last week when I audited my ssh config and dropped all
>> weak/slow ciphers.
>> Couldn't log into my routers and had to add md5 ciphers and macs back.
>>
> You must rebuild dropbear package cleanly to test this patch
> 
> Save the patch as file located on
> package/network/services/dropbear/patches/600-enable-hmac-sha2.patch,
> relative to OpenWrt source directory. The patch is available here
> http://patchwork.openwrt.org/patch/6322/
> 
> Do "make clean" to clean up the package, and then "make" to build the
> firmware.
> Flash the resulting firmware and test connecting to dropbear ssh daemon.
> 
> To test using hmac-sha2-256, run this command
> ssh -o MACs=hmac-sha2-256 root@OpenWrt
> To test using hmac-sha2-512, run this command
> ssh -o MACs=hmac-sha2-512 root@OpenWrt
> 
> For your information, there is almost no difference between message
> authentication algorithm in time needed to establish ssh connection.
> 
> I perform the test on my TL-MR3220 (AR9330, mips, dropbear 2014.65,
> r42321). The identity file is cached via ssh-agent. The test commands
> are bellow.
> time ssh -o MACs=hmac-md5 OpenWrt /bin/true
> time ssh -o MACs=hmac-sha1 OpenWrt /bin/true
> time ssh -o MACs=hmac-sha2-256 OpenWrt /bin/true
> time ssh -o MACs=hmac-sha2-512 OpenWrt /bin/true
> 
> Here are time needed to establish ssh connection
> +-+--+--+--+--+
> |time\hmac|md5   |   sha1   |  sha256  |  sha512  |
> +-+--+--+--+--+
> | real| 0m3.526s | 0m3.631s | 0m3.519s | 0m3.543s |
> | user| 0m0.015s | 0m0.061s | 0m0.015s | 0m0.031s |
> | sys | 0m0.077s | 0m0.046s | 0m0.093s | 0m0.092s |
> +-+--+--+--+--+
> 
> Putty and Bitvise will try connecting using hmac-sha2-256 when
> available, whereas OpenSSH will use hmac-md5 by default.
> 
> I hope this information will be a good reason for enabling sha2-based
> hmac on dropbear by default.
> 

Based off failed ciphers/macs
no matching cipher found: client rijndael-...@lysator.liu.se server
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc
no matching mac found: client hmac-ripemd160-...@openssh.com server
hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5

for cipher in 3des-cbc 3des-ctr aes128-cbc aes256-cbc aes128-ctr
aes256-ctr; do for mac in hmac-md5 hmac-sha1 hmac-sha2-256
hmac-sha2-512; do echo ""; echo "cipher: $cipher"; echo "mac: $mac"; for
bah in 1 2 3; do dd if=/dev/zero bs=1M count=25 | ssh -c "$cipher" -m
"$mac" -o "Compression no" r...@openwrt.lan 'time cat - >/dev/null';
echo ""; sleep 2; done; done; done

OpenSSH_6.6.1 connecting to TP-Link 4300, time to transfer 26MiB of junk
to null. Best of three, my router is in use and not idle.

3des-cbc
+-+--+--+--+--+
|time\hmac|md5   |   sha1   |  sha256  |  sha512  |
+-+--+--+--+--+
| real| 0m27.65s | 0m27.98s | 0m29.47s | 0m31.93s |
| user| 0m 0.05s | 0m 0.04s | 0m 0.02s | 0m 0.04s |
| sys | 0m 0.25s | 0m 0.22s | 0m 0.24s | 0m 0.22s |
+-+--+--+--+--+

aes128-cbc
+-+--+--+--+--+
|time\hmac|md5   |   sha1   |  sha256  |  sha512  |
+-+--+--+--+--+
| real| 0m12.07s | 0m12.62s | 0m13.61s | 0m16.05s |
| user| 0m 0.02s | 0m 0.03s | 0m 0.00s | 0m 0.02s |
| sys | 0m 0.27s | 0m 0.23s | 0m 0.21s | 0m 0.22s |
+-+--+--+--+--+

aes256-cbc
+-+--+--+--+--+
|time\hmac|md5   |   sha1   |  sha256  |  sha512  |
+-+--+--+--+--+
| real| 0m13.32s | 0m13.61s | 0m14.97s | 0m17.71s |
| user| 0m 0.02s | 0m 0.03s | 0m 0.03s | 0m 0.03s |
| sys | 0m 0.27s | 0m 0.23s | 0m 0.22s | 0m 0.28s |
+-+--+--+--+--+

aes128-ctr
+-+--+--+--+--+
|time\hmac|md5   |   sha1   |  sha256  |  sha512  |
+-+--+--+--+--+
| real| 0m12.64s | 0m12.80s | 0m13.74s | 0m16.19s |
| user| 0m 0.04s | 0m 0.02s | 0m 0.02s | 0m 0.01s |
| sys | 0m 0.18s | 0m 0.24s | 0m 0.17s | 0m 0.23s |
+-+--+--+--+--+

aes256-ctr
+-+--+--+--+--+
|time\hmac|md5   |   sha1   |  sha256  |  sha512  |
+-+--+--+--+--+
| real| 0m13.40s | 0m13.84s | 0m15.20s | 0m18.11s |
| user| 0m 0.01s | 0m 0.03s | 0m 0.02s | 0m 0.00s |
| sys | 0m 0.17s | 0m 0.16s | 0m 0.18s | 0m 0.24s |
+-+--+--+--+--+


We should dump 3des-* and pick up arcfour*
___
openwrt-devel mailing list
openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: remove error from detect script

[John Crispin]

On 03/10/2014 19:37, Jo-Philipp Wich wrote:
> Hi Michel, John.
>
>>> -   for dev in $(ls /sys/class/ieee80211); do
>>> +   for dev in $(ls /sys/class/ieee80211 2>/dev/null); do
>> what error do you see ? if you see an error we should try to fix that
>> rather than supressing it
> I suppose the case when "wifi detect" is invoked but no phy exists on
> the system (e.g. because the radio hardware is not installed - think USB).
>
> In this case the entire /sys/class/ieee80211 is likely missing which
> will cause "ls" to print a "No such file or directory" error.
>
> Actually I do not really like that whole "for x in $(ls ...)" construct,
> something like the following would save one fork and also not produce
> errors:
>
> for dev in /sys/class/ieee80211/*; do
> if [ -h "$dev" ]; then
>  # do something with ${dev##*/}
> fi
> done
the change from AutoLoad to AutoProbe will cause cfg80211 to not be
loaded if no driver is loaded. hence ieee80211 is missing.

the for loop make sense ...


>
> ~ Jow
> ___
> 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] [Cerowrt-devel] better ingress shaping somehow

[Sebastian Moeller]

Hi Dave,


On Oct 3, 2014, at 01:07 , Dave Taht  wrote:
[cut a lot...]
> But: the real killer, on ingress shaping, is the call to skb_clone in
> sch_ingress->act_mirred path, I think.

So I thought that we basically have around 50Mbps “shaping-capability” 
on the wndrs which hew can distribute between egress and ingress, but if your 
analysis is correct wouldn’t that mean that shaping egress is cheaper? (Not 
that this has much relevance in the real world due uplink << downlink asymmetry 
the ISPs push onto us endusers)

> 
> If it were possible to have sch_cake replace sch_ingress, that would
> be a huge win, but following the call path for why that must be cloned
> has thus far resisted my archeological expertise. An network ninja
> is needed here
[…]

;) 

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

[OpenWrt-Devel] Atheros AR231x MIPS machine name (ex [PATCH 01/16] MIPS: ar231x: add common parts)

[Sergey Ryazanov]

Add owrt mailing list to cc.

Any suggestions?

2014-09-30 0:57 GMT+04:00 Sergey Ryazanov :
> 2014-09-29 13:30 GMT+04:00 Jonas Gorski :
>> On Sun, Sep 28, 2014 at 8:33 PM, Sergey Ryazanov  
>> wrote:
>>> Add common code for Atheros AR5312 and Atheros AR2315 SoCs families.
>>>
[...]
>>>
>>> +config AR231X
>>
>> I would suggest naming it ATH25, to match the other atheros target (ATH79).
> I have been thinking about such name. But decided to keep code closer
> to owrt realization. May be maintainers could suggest smth. Ralf, what
> do you think?
>

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

Re: [OpenWrt-Devel] [PATCH] at91: remove support for TQMa9263

[John Crispin]

EOL as in not produced anymore or has no existing users ?

On 23/09/2014 21:33, Michael Heimpold wrote:
> This board is EOL, we should not bother anymore with it.
> 
> Signed-off-by: Michael Heimpold  --- 
> .../files-3.10/arch/arm/mach-at91/board-tqma9263.c |  219
>  
> .../files-3.14/arch/arm/mach-at91/board-tqma9263.c |  219
>  
> .../at91/patches-3.10/700-tqma9263-support.patch   |   25 --- 
> .../at91/patches-3.14/700-tqma9263-support.patch   |   25 --- 4
> files changed, 488 deletions(-) delete mode 100644
> target/linux/at91/files-3.10/arch/arm/mach-at91/board-tqma9263.c 
> delete mode 100644
> target/linux/at91/files-3.14/arch/arm/mach-at91/board-tqma9263.c 
> delete mode 100644
> target/linux/at91/patches-3.10/700-tqma9263-support.patch delete
> mode 100644
> target/linux/at91/patches-3.14/700-tqma9263-support.patch
> 
> diff --git
> a/target/linux/at91/files-3.10/arch/arm/mach-at91/board-tqma9263.c
> b/target/linux/at91/files-3.10/arch/arm/mach-at91/board-tqma9263.c 
> deleted file mode 100644 index cae1fe9..000 ---
> a/target/linux/at91/files-3.10/arch/arm/mach-at91/board-tqma9263.c 
> +++ /dev/null @@ -1,219 +0,0 @@ -/* - *  Copyright (C) 2008 I2SE
> GmbH - *  Copyright (C) 2010 IEQualize GmbH - *  Copyright (C)
> 2010-2011 Michael Heimpold - * - * This program is free software;
> you can redistribute it and/or modify - * it under the terms of the
> GNU General Public License as published by - * the Free Software
> Foundation; either version 2 of the License, or - * (at your
> option) any later version. - * - * This program is distributed in
> the hope that it will be useful, - * but WITHOUT ANY WARRANTY;
> without even the implied warranty of - * MERCHANTABILITY or FITNESS
> FOR A PARTICULAR PURPOSE.  See the - * GNU General Public License
> for more details. - * - * You should have received a copy of the
> GNU General Public License - * along with this program; if not,
> write to the Free Software - * Foundation, Inc., 59 Temple Place,
> Suite 330, Boston, MA  02111-1307  USA - */ - -#include
>  -#include  -#include  
> -#include  -#include  
> -#include  - -#include  -#include
>  -#include  -#include  - 
> -#include  -#include  -#include
>  - -#include  -#include
>  -#include  - -#include
>  - -#include "sam9_smc.h" -#include
> "generic.h" - -#include  - - -static void
> __init tqma9263_map_io(void) -{ - unsigned pins; - -  /* Initialize
> processor: 18.432 MHz crystal */ -at91_initialize(18432000); - -
> /* DGBU on ttyS0. (Rx & Tx only) */ - at91_register_uart(0, 0, 0); 
> - -   /* USART0 on ttyS1 */ - pins = ATMEL_UART_CTS | ATMEL_UART_RTS
> | -  ATMEL_UART_DSR | ATMEL_UART_DTR | -
> ATMEL_UART_DCD | ATMEL_UART_RI; -
> at91_register_uart(AT91SAM9263_ID_US0, 1, pins); - -  /* USART1 on
> ttyS2 */ -pins = ATMEL_UART_RTS; -
> at91_register_uart(AT91SAM9263_ID_US1, 2, pins); - -  /* USART2 on
> ttyS3 */ -pins = ATMEL_UART_RTS; -
> at91_register_uart(AT91SAM9263_ID_US2, 3, pins); - -  /* set serial
> console to ttyS0 (ie, DBGU) */ -  at91_set_serial_console(0); -} - 
> - -/* - * USB Host port - */ -static struct at91_usbh_data
> __initdata tqma9263_usbh_data = { -   .ports  = 2, -  
> .vbus_pin   = {
> AT91_PIN_PA24, AT91_PIN_PA21 }, - .vbus_pin_active_low= 0, -}; - 
> - -/* - * USB Device port - */ -static struct at91_udc_data
> __initdata tqma9263_udc_data = { -.vbus_pin   = AT91_PIN_PA25, -
> .pullup_pin   = 0,/* pull-up driven by UDC */ -}; - - -/* 
> - * MCI
> (SD/MMC) - */ -static struct at91_mmc_data __initdata
> tqma9263_mmc_data = { -   .wire4  = 1, -  .det_pin= 
> AT91_PIN_PE18, -
> .wp_pin   = AT91_PIN_PB28, -}; - - -/* - * MACB Ethernet device -
> */ -static struct macb_platform_data __initdata tqma9263_macb_data
> = { - .phy_irq_pin= AT91_PIN_PE31, -  .is_rmii= 1, -}; - - 
> -/* - *
> I2C devices - */ -static struct i2c_board_info __initdata
> tqma9263_i2c_devices[] = { -  { - I2C_BOARD_INFO("pcf8563", 
> 0x51), 
> - }, -{ - I2C_BOARD_INFO("24c04", 0x52), -}, -}; 
> - - -/* - *
> NAND flash - */ -static struct mtd_partition __initdata
> tqma9263_nand_partition[] = { -   { - .name   = "uboot", -
> .offset =
> 0, -  .size   = 3 * SZ_128K, -}, -{ - .name   
> = "uboot-env", -
> .offset   = MTDPART_OFS_NXTBLK, - .size   = SZ_128K, -}, -
> { - .name
> = "linux", -  .offset = MTDPART_OFS_NXTBLK, - .size   = 
> SZ_2M, -  }, 
> - { - .name   = "rootfs", -   .offset = 
> MTDPART_OFS_NXTBLK, - .size
> = MTDPART_SIZ_FULL, - }, -}; - -static struct mtd_partition *
> __init nand_partitions(int size, int *num_partitions) -{ -
> *num_partitions = ARRAY_SIZE(tqma9263_nand_partition); -  return
> tqma9263_nand_partition; -} - -st

Re: [OpenWrt-Devel] [PATCHv3 2/3] [package] gpio-button-hotplug: Add a "mode" event

[John Crispin]

have a look at FONER20N.dts

switch {
label = "switch";
gpios = <&gpio0 13 1>;
linux,code = <0xf7>;
linux,input-type = <5>; /* EV_SW */
};

that would obsolete 2 and you need to change 3. i have merged 1 into
my tree.

On 17/09/2014 10:22, Russell Senior wrote:
> 
> diff --git
> a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
> b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
> index c997e35..891dd96 100644 ---
> a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c +++
> b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c @@
> -97,6 +97,7 @@ static struct bh_map button_map[] = { 
> BH_MAP(KEY_RFKILL,"rfkill"), BH_MAP(KEY_WPS_BUTTON,   "wps"), 
> BH_MAP(KEY_WIMAX, "wwan"), +  BH_MAP(BTN_MODE,"mode"), };
> 
> /*
> -*/
>
> 
-- 
> 2.0.0
> 
> Hmm.
> 
> If we used KEY_M here instead of horribly abusing BTN_MODE, the
> third patch would be unnecessary.
> 
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Nexx WT1520

[John Crispin]

the patch does not apply anymore. can you rebase it and send it again
please ?

On 17/09/2014 13:38, open...@rogerpueyo.com wrote:
> From: Roger Pueyo Centelles 
> 
> --- target/linux/ramips/base-files/etc/board.d/01_leds |  3 + 
> .../linux/ramips/base-files/etc/board.d/02_network |  1 + 
> target/linux/ramips/base-files/etc/diag.sh |  3 + 
> target/linux/ramips/base-files/lib/ramips.sh   |  3 + 
> .../ramips/base-files/lib/upgrade/platform.sh  |  1 + 
> target/linux/ramips/dts/NEXXWT1520.dts | 83
> ++ target/linux/ramips/image/Makefile
> |  8 +++ target/linux/ramips/rt305x/profiles/nexx.mk| 17
> + 8 files changed, 119 insertions(+) create mode 100644
> target/linux/ramips/dts/NEXXWT1520.dts create mode 100644
> target/linux/ramips/rt305x/profiles/nexx.mk
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
> b/target/linux/ramips/base-files/etc/board.d/01_leds index
> 01e2363..1806ff2 100755 ---
> a/target/linux/ramips/base-files/etc/board.d/01_leds +++
> b/target/linux/ramips/base-files/etc/board.d/01_leds @@ -112,6
> +112,9 @@ case $board in hlk-rm04) set_wifi_led
> "rt2800pci-phy0::radio" ;; +  nexx-wt1520) +  set_wifi_led
> "rt2800pci-phy0::radio" + ;; all0239-3g|\ hw550-3g) set_usb_led
> "hw550-3g:green:usb" diff --git
> a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network index
> e027b3b..765d398 100755 ---
> a/target/linux/ramips/base-files/etc/board.d/02_network +++
> b/target/linux/ramips/base-files/etc/board.d/02_network @@ -103,6
> +103,7 @@ ramips_setup_interfaces() dir-320-b1 | \ dir-615-h1 | \ 
> hlk-rm04 | \ +nexx-wt1520 | \ mzk-w300nh2 | \ mzk-750dhp) 
> ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" diff --git
> a/target/linux/ramips/base-files/etc/diag.sh
> b/target/linux/ramips/base-files/etc/diag.sh index 9ad7ccb..472da4b
> 100755 --- a/target/linux/ramips/base-files/etc/diag.sh +++
> b/target/linux/ramips/base-files/etc/diag.sh @@ -63,6 +63,9 @@
> get_status_led() { hlk-rm04) status_led="hlk-rm04:red:power" ;; +
> nexx-wt1520) +status_led="nexx-wt1520:white:power" +  
> ;; 
> all0239-3g|\ hw550-3g) status_led="hw550-3g:green:status" diff
> --git a/target/linux/ramips/base-files/lib/ramips.sh
> b/target/linux/ramips/base-files/lib/ramips.sh index
> bb42ace..0a09225 100755 ---
> a/target/linux/ramips/base-files/lib/ramips.sh +++
> b/target/linux/ramips/base-files/lib/ramips.sh @@ -157,6 +157,9 @@
> ramips_board_detect() { *"HILINK HLK-RM04") name="hlk-rm04" ;; +
> *"Nexx WT1520") + name="nexx-wt1520" +;; *"HAME 
> MPR-A1") 
> name="mpr-a1" ;; diff --git
> a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh index
> 407c218..8ff2da6 100755 ---
> a/target/linux/ramips/base-files/lib/upgrade/platform.sh +++
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh @@ -52,6
> +52,7 @@ platform_check_image() { hw550-3g | \ hg255d | \ hlk-rm04
> | \ + nexx-wt1520 | \ ip2202 | \ m3 | \ m4 | \ diff --git
> a/target/linux/ramips/dts/NEXXWT1520.dts
> b/target/linux/ramips/dts/NEXXWT1520.dts new file mode 100644 index
> 000..dc0ad32 --- /dev/null +++
> b/target/linux/ramips/dts/NEXXWT1520.dts @@ -0,0 +1,83 @@ 
> +/dts-v1/; + +/include/ "rt5350.dtsi" + +/ { +compatible =
> "NEXXWT1520", "ralink,rt5350-soc"; +  model = "Nexx WT1520"; + +
> memory@0 { +  device_type = "memory"; +   reg = <0x0 
> 0x200>; +
> }; + +chosen { +  bootargs = "console=ttyS1,57600"; + 
> }; + +
> palmbus@1000 { +  uart@500 { +status = 
> "okay"; +  }; + +
> spi@b00 { +   status = "okay"; +  
> m25p80@0 { +#address-cells =
> <1>; +#size-cells = <1>; +
> compatible = "w25q32"; +reg =
> <0 0>; +  linux,modalias = "m25p80", "s25fl064k"; 
> +
> spi-max-frequency = <1000>; + +   partition@0 { + 
> label =
> "u-boot"; +   reg = <0x0 0x3>; +  
> read-only; +}; + +
> partition@3 { +   label = "u-boot-env"; + 
> reg = <0x3
> 0x1>; +   read-only; +
> }; + +  factory: partition@4
> { +   label = "factory"; +
> reg = <0x4 0x1>; +
> read-only; +  }; + +  
> partition@5 { + label =
> "firmware"; +

Re: [OpenWrt-Devel] [PATCH 1/3] ar71xx: simplify TP-LINK model detection

[John Crispin]

On 01/09/2014 17:53, Matthias Schiffer wrote:
> All TP-LINK machine names begin with "TP-LINK", so there's no need
> to check for more specific model names. This also allows adding new
> models like the Archer series more easily.
> 

are you sure, that they *all* start with TP-LINK ?




> Signed-off-by: Matthias Schiffer  
> --- target/linux/ar71xx/base-files/lib/ar71xx.sh | 6 +- 1 file
> changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh index
> 1e96b6d..d26ac3d 100755 ---
> a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -744,11 +744,7 @@
> ar71xx_board_detect() { ;; esac
> 
> - case "$machine" in -*TL-WR* | *TL-WA* | *TL-MR* | *TL-WD*) -
> tplink_board_detect "$machine" -  ;; -esac +  [ 
> "${machine:0:8}" =
> 'TP-LINK ' ] && tplink_board_detect "$machine"
> 
> [ -z "$name" ] && name="unknown"
> 
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] netifd: implement zeroconf

[John Crispin]

On 02/10/2014 15:41, Michel Stam wrote:
> The scripts were based on the netifd dhcp scripts, and should add
> zeroconf support to /etc/config/network Example: config interface
> 'lan' option ifname 'eth0' option auto '0' option proto 'zeroconf'
> 
> Optionally, the desired IP address can be added by: option ipaddr
> '169.254.200.100'
> 
> any extra commandline arguments can be added by: option cmdline
> '-v'
> 

-l  is the only option not explicitly defined. you should
rename cmdline and make it only hold 

we should also see about splitting zcip out into a standalone tool



> Note that zcip in Busybox must be enabled for this to work.
> 
> Signed-off-by: Michel Stam  --- 
> .../netifd/files/lib/netifd/proto/zeroconf.sh  | 33
> ++ 
> .../config/netifd/files/lib/netifd/zeroconf.script | 29
> +++ 2 files changed, 62 insertions(+) create mode
> 100755
> package/network/config/netifd/files/lib/netifd/proto/zeroconf.sh 
> create mode 100755
> package/network/config/netifd/files/lib/netifd/zeroconf.script
> 
> diff --git
> a/package/network/config/netifd/files/lib/netifd/proto/zeroconf.sh
> b/package/network/config/netifd/files/lib/netifd/proto/zeroconf.sh 
> new file mode 100755 index 000..cec7605 --- /dev/null +++
> b/package/network/config/netifd/files/lib/netifd/proto/zeroconf.sh 
> @@ -0,0 +1,33 @@ +#!/bin/sh + +. /lib/functions.sh +.
> ../netifd-proto.sh +init_proto "$@" + +proto_zeroconf_init_config()
> { +   proto_config_add_string 'ipaddr:ipaddr' +
> proto_config_add_string cmdline +} + +proto_zeroconf_setup() { +
> local config="$1" +   local iface="$2" + +local ipaddr +
> json_get_vars ipaddr cmdline + +  proto_export "INTERFACE=$config" +
> proto_run_command "$config" zcip \ +  ${ipaddr:+-r $ipaddr} \ +
> ${cmdline} \ +-f "$iface" \ + 
> /lib/netifd/zeroconf.script +} + 
> +proto_zeroconf_teardown() { +local interface="$1" +
> proto_kill_command "$INTERFACE" +} + +add_protocol zeroconf + diff
> --git
> a/package/network/config/netifd/files/lib/netifd/zeroconf.script
> b/package/network/config/netifd/files/lib/netifd/zeroconf.script 
> new file mode 100755 index 000..8d34a67 --- /dev/null +++
> b/package/network/config/netifd/files/lib/netifd/zeroconf.script @@
> -0,0 +1,29 @@ +#!/bin/sh +[ -z "$1" ] && echo "Error: should be run
> by zcip" && exit 1 + +. /lib/functions.sh +.
> /lib/netifd/netifd-proto.sh + +setup_interface () { +
> proto_init_update "*" 1 + proto_add_ipv4_address "$ip"
> '255.255.0.0' +   proto_send_update "$INTERFACE" +} + 
> +deconfig_interface() { + proto_init_update "*" 0 +
> proto_send_update "$INTERFACE" +} + +case "$1" in +   deconfig) +
> deconfig_interface +  ;; +config) +   setup_interface +   
> ;; +
> *|init) + ;; +esac + +exit 0
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] ar71xx: simplify TP-LINK model detection

[Matthias Schiffer]

On 10/03/2014 10:23 PM, John Crispin wrote:
> 
> 
> On 01/09/2014 17:53, Matthias Schiffer wrote:
>> All TP-LINK machine names begin with "TP-LINK", so there's no need
>> to check for more specific model names. This also allows adding new
>> models like the Archer series more easily.
>>
> 
> are you sure, that they *all* start with TP-LINK ?
Yes, I've checked all machine strings defined in
target/linux/ar71xx/files/arch/mips/ath79/*; everything that contains
one of the four old match strings starts with TP-LINK.

> 
> 
> 
> 
>> Signed-off-by: Matthias Schiffer  
>> --- target/linux/ar71xx/base-files/lib/ar71xx.sh | 6 +- 1 file
>> changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> b/target/linux/ar71xx/base-files/lib/ar71xx.sh index
>> 1e96b6d..d26ac3d 100755 ---
>> a/target/linux/ar71xx/base-files/lib/ar71xx.sh +++
>> b/target/linux/ar71xx/base-files/lib/ar71xx.sh @@ -744,11 +744,7 @@
>> ar71xx_board_detect() { ;; esac
>>
>> -case "$machine" in -*TL-WR* | *TL-WA* | *TL-MR* | *TL-WD*) -
>> tplink_board_detect "$machine" - ;; -esac +  [ 
>> "${machine:0:8}" =
>> 'TP-LINK ' ] && tplink_board_detect "$machine"
>>
>> [ -z "$name" ] && name="unknown"
>>
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 




signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing 'noexecstack' in uClibc MIPS builds

[Andrew McDonnell]

True. Perhaps that makes it a moot issue for BB.
But I dont think it would hurt to be ahead of the curve in this day and age...

I am not the only one  adding this latent protection to MIPS:

https://webrtc-codereview.appspot.com/994006/
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02430.html  (source of my patch 
submission which I emailed later when I finally cracked this)

http://lists.busybox.net/pipermail/uclibc/2014-August/048474.html

The trade-off might be giving people a false sense of protection, I guess. But 
that could happen anyway once the fix meanders tghrough gcc upstream. Then 
again, who else before me even bothered to scan their router files for this :-)


Of lower priority for OpenWRT mainstream, is a determined user could also 
cherry-pick emulated NX protection from PAX.
When they google this problem they will at least find my work. Which was a 
great learning exercise regardless. I blogged about it here --> 
http://blog.oldcomputerjunk.net/


Anyways, up to you I guess. I am still learning this stuff. Its not like the 
"experts" regularly get security stuff right...


cheers,
--Andrew


On 04/10/14 02:54, Felix Fietkau wrote:

On 2014-10-03 19:14, Catalin Patulea wrote:

On Wed, Oct 1, 2014 at 6:42 PM, Andrew McDonnell
 wrote:

It seems that OpenWRT sets the relevant flag to require uClibc to build with
NOEXECSTACK set. This is good.  (For one introduction to NOEXECSTACK, see
http://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart )

Does anything actually enforce NX on MIPS?

There are MIPS CPUs that support it, but my guess is that most of our
MIPS targets don't have any hardware support for it.

- Felix


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

[OpenWrt-Devel] OpenWRT support for MPR-A1

[Stefan Monnier]

AFAICT OpenWRT comes with some support for the Hame MPR-A1 thingy
(although its 16MB of RAM and 4MB of flash probably prevent it from
being fully supported).

I had no trouble building an image for it, but now I'm wondering how to
install that image.  I went to http://wiki.openwrt.org/toh/hame/mpr-a1
which gives various information, but it doesn't say how to actually
install an image on that box.

The page for MPR-A2 (whose hardware and firmware seem very similar) says
that the image can be installed via the factory web UI.
Does someone know if that would work for the MPR-A1 as well?
And if it doesn't work, would it just immediately fail, leaving the
factory firmware untouched, or would it result in an unbootable machine
(and if so would it be recoverable via the serial console)?


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