Re: [OpenWrt-Devel] New gstreamer packages

2014-07-15 Thread Sergey Korolew 
Hello !

SB the oldpackages feed is unsupported and will not be updated any more.
SB If you want to submit packages or adopt packages from oldpackages which
SB are not there yet please go to
SB https://github.com/openwrt/packages and 
SB make a pull request there.

I wondering why drop so many working packages even if they not maintained 
anymore.
Multimedia part now have 2 items, instead of ~30 in oldpackages.

Thanks for the answer, but I does not interested to be maintainer
(as listed in README).


-- 
 Sergey  mailto:d...@bittu.org.ru
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-15 Thread Nikolai Zhubr 

15.07.2014 1:42, Jonas Gorski:
[...]

or
bw32(bp, B44_RXMAXLEN, bp-dev-mtu + ETH_HLEN + 8) ?


This is the right one; mtu (the payload) + ETH_HLEN (14 bytes) + 8
(4 bytes for vlan tag, probably 4 extra bytes for custom header
optionally used by broadcom switches)


Ok, tested this. Unfortunately it's still panicing under load (and 
seemingly this change made no difference whatsoever):



[  271.21] [ cut here ]
[  271.22] WARNING: at net/core/dev.c:2194 
skb_warn_bad_offload+0xc0/0xe8()
[  271.22] b44: caps=(0x4000, 0x) 
len=377 data_len=0 gso_size=57048 gso_type=32506 ip_summed=0
[  271.24] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core

[  271.30] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.44 #2
[  271.30] Stack :     8030d552 
0036 818201d0 0008

  80272688 802bf23b 0003 8030cd00 818201d0 0008 802bb6e4 

  802bb6dc 8001c204 0003 80019bc4 80299520 0008 80273f28 
8182bc5c
         

         
8182bbe8
  ...
[  271.34] Call Trace:
[  271.34] [80010ca0] show_stack+0x48/0x70
[  271.35] [80019cc0] warn_slowpath_common+0x78/0xa8
[  271.35] [80019d1c] warn_slowpath_fmt+0x2c/0x38
[  271.36] [801b2d10] skb_warn_bad_offload+0xc0/0xe8
[  271.36] [801b68c4] __skb_gso_segment+0x50/0xec
[  271.37] [801de5bc] ip_forward_finish+0x108/0x1bc
[  271.37] [801b3da0] __netif_receive_skb_core+0x46c/0x52c
[  271.38] [81ad41d4] 0x81ad41d4
[  271.38]
[  271.38] ---[ end trace b4f0aa7175b12bf7 ]---
[  271.39] Unhandled kernel unaligned access[#1]:
[  271.39] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: GW 
3.10.44 #2

[  271.39] task: 81820028 ti: 8182a000 task.ti: 8182a000
[  271.39] $ 0   :  0001 81696a48 0028
[  271.39] $ 4   : 2d37d9ee  7088 
[  271.39] $ 8   : 002d 35373137 62323162 5d203766
[  271.39] $12   :  03bf  bc00
[  271.39] $16   : 80e7fec0 0001 0001 0014
[  271.39] $20   :  0008 802bb6e4 
[  271.39] $24   : 0003 80150bcc
[  271.39] $28   : 8182a000 8182bd28 802bb6dc 801ab22c
[  271.39] Hi: 
[  271.39] Lo: 0083
[  271.39] epc   : 80064440 put_page+0x0/0x4c
[  271.39] Tainted: GW
[  271.39] ra: 801ab22c skb_release_data+0xc4/0x118
[  271.39] Status: 1000b803 KERNEL EXL IE
[  271.39] Cause : 00800010
[  271.39] BadVA : 2d37d9ee
[  271.39] PrId  : 00029006 (Broadcom BMIPS3300)
[  271.39] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[  271.39] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000, 
task=81820028, tls=)
[  271.39] Stack : 80e7fec0 801ab294 80e7fec0 7088  
80e7fec0 ffea 801ab2d0

  802bb6e4 80e7fec0 80e5da40 0001 80e7fec0 801de5d4 0850 
80f72ac0
  81b68000 801de4b4 0001 801aa3e4 802bca98 802bca98 802bb6d0 
81abc000
  80e7fec0 801b3da0 0042 81ad0964 81b7df20 801aa3e4 802bb6e4 
8018e658
  010a 01f1 81abc3e8 81abc3c0 0042 80e7fec0 0017 
0187
  ...
[  271.39] Call Trace:
[  271.39] [80064440] put_page+0x0/0x4c
[  271.39] [801ab22c] skb_release_data+0xc4/0x118
[  271.39] [801ab2d0] __kfree_skb+0x14/0xd4
[  271.39] [801de5d4] ip_forward_finish+0x120/0x1bc
[  271.39] [801b3da0] __netif_receive_skb_core+0x46c/0x52c
[  271.39] [81ad41d4] 0x81ad41d4
[  271.39]
[  271.39]
Code: 3c058006  080190c9  24a538e4 8c82

Re: [OpenWrt-Devel] New gstreamer packages

2014-07-15 Thread Dirk Neukirchen 
On 13.07.2014 09:00, Sergey Korolew wrote:
 Hello !
 
 I created several new gstreamer module packages (v4l2 for example),
 they update makefiles and add some patches.
 But now I confused with paths, after update gstreamer was moved to
 the oldpackages directory. Which path patch should contain ?
 
 

to quote Steven Barth who replied to a similar mail:

 please note that we are not going to accept patches for the (old) 
 packages feed anymore.
 See: https://forum.openwrt.org/viewtopic.php?id=51078 and the referenced 
 mail for details.
 
 If you like you can adopt this package and maintain it in our new github 
 feed: https://github.com/openwrt/packages though.

gstreamer is not available in github packages.
It has to be there first to get your patch accepted.

There are patches for gst1-...-... that has a newer api than the one available 
in
OpenWrt oldpackages. Most of these build fine
see http://patchwork.openwrt.org/patch/4982/ and later
or the mailing list archive.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: update Carambola2 platform data

2014-07-15 Thread Mantas Pucka 
Tested building for carambola2 target.

Signed-off-by: Mantas Pucka man...@8devices.com
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c | 9 -
 target/linux/ar71xx/image/Makefile  | 2 +-
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
index e7bc861..babe101 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
@@ -25,7 +25,6 @@
 #define CARAMBOLA2_GPIO_LED_ETH1   13
 
 #define CARAMBOLA2_GPIO_BTN_JUMPSTART  11
-#define CARAMBOLA2_GPIO_BTN_RESET  12
 
 #define CARAMBOLA2_KEYS_POLL_INTERVAL  20  /* msecs */
 #define CARAMBOLA2_KEYS_DEBOUNCE_INTERVAL  (3 * 
CARAMBOLA2_KEYS_POLL_INTERVAL)
@@ -60,14 +59,6 @@ static struct gpio_keys_button carambola2_gpio_keys[] 
__initdata = {
.gpio   = CARAMBOLA2_GPIO_BTN_JUMPSTART,
.active_low = 1,
},
-   {
-   .desc   = reset button,
-   .type   = EV_KEY,
-   .code   = KEY_RESTART,
-   .debounce_interval = CARAMBOLA2_KEYS_DEBOUNCE_INTERVAL,
-   .gpio   = CARAMBOLA2_GPIO_BTN_RESET,
-   .active_low = 1,
-   }
 };
 
 static void __init carambola2_common_setup(void)
diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index 822f95d..2b88a8f 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -248,7 +248,7 @@ 
ap96_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,6144k(rootfs),17
 
ap113_mtd_layout=mtdparts=spi0.0:64k(u-boot),3008k(rootfs),896k(uImage),64k(NVRAM),64k(ART),3904k@0x1(firmware)
 
ap121_mtdlayout_2M=mtdparts=spi0.0:64k(u-boot)ro,1216k(rootfs),704k(kernel),64k(art)ro,1920k@0x1(firmware)
 
ap121_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware)
-carambola2_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,15936k(firmware),64k(nvram),64k(art)ro
+carambola2_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro
 
ap132_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),6400k(rootfs),64k(art),7808k@0x5(firmware)
 
ap135_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14528k(rootfs),1472k(kernel),64k(art)ro,16000k@0x5(firmware)
 
ap136_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(mib0),64k(art)ro,7744k@0x5(firmware)
-- 
1.8.1.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: update Carambola2 platform data

2014-07-15 Thread Mantas Pucka 

Sorry, change list got cut off in previous mail:

ar71xx: update Carambola2 platform data

 * Remove button info on GPIO12, there is no button there.
 * Remove nvram mtd partition, as it's not used for anything, saves 
64k for user data

Tested building for carambola2 target.

Signed-off-by: Mantas Pucka man...@8devices.com
---
  target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c | 9 -
  target/linux/ar71xx/image/Makefile  | 2 +-
  2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
index e7bc861..babe101 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-carambola2.c
@@ -25,7 +25,6 @@
  #define CARAMBOLA2_GPIO_LED_ETH1  13
  
  #define CARAMBOLA2_GPIO_BTN_JUMPSTART		11

-#define CARAMBOLA2_GPIO_BTN_RESET  12
  
  #define CARAMBOLA2_KEYS_POLL_INTERVAL		20	/* msecs */

  #define CARAMBOLA2_KEYS_DEBOUNCE_INTERVAL (3 * 
CARAMBOLA2_KEYS_POLL_INTERVAL)
@@ -60,14 +59,6 @@ static struct gpio_keys_button carambola2_gpio_keys[] 
__initdata = {
.gpio   = CARAMBOLA2_GPIO_BTN_JUMPSTART,
.active_low = 1,
},
-   {
-   .desc   = reset button,
-   .type   = EV_KEY,
-   .code   = KEY_RESTART,
-   .debounce_interval = CARAMBOLA2_KEYS_DEBOUNCE_INTERVAL,
-   .gpio   = CARAMBOLA2_GPIO_BTN_RESET,
-   .active_low = 1,
-   }
  };
  
  static void __init carambola2_common_setup(void)

diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index 822f95d..2b88a8f 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -248,7 +248,7 @@ 
ap96_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,6144k(rootfs),17
  
ap113_mtd_layout=mtdparts=spi0.0:64k(u-boot),3008k(rootfs),896k(uImage),64k(NVRAM),64k(ART),3904k@0x1(firmware)
  
ap121_mtdlayout_2M=mtdparts=spi0.0:64k(u-boot)ro,1216k(rootfs),704k(kernel),64k(art)ro,1920k@0x1(firmware)
  
ap121_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware)
-carambola2_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,15936k(firmware),64k(nvram),64k(art)ro
+carambola2_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,16000k(firmware),64k(art)ro
  
ap132_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),6400k(rootfs),64k(art),7808k@0x5(firmware)
  
ap135_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14528k(rootfs),1472k(kernel),64k(art)ro,16000k@0x5(firmware)
  
ap136_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(mib0),64k(art)ro,7744k@0x5(firmware)

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

[OpenWrt-Devel] When to use Target Profile or Subtarget

2014-07-15 Thread Claudio Thomas 
Hi,
I'm adapting the Freescale MPC83xx platform, so that multiple devices
can be selected.
Actually the following boards are in use, but hard-coded over files or
file-patches and not selectable be menuconfig
- RouterBOARD 333
- RouterBOARD 600
This makes it unnecessary difficult to add new devices.

I've scanned on other platforms to see how this is generally done.
There seems to be three mainstreams:
Target Profile to select the Board implementation (like
AR7xxx/AT91/BCM47xx/ADM5120),
Subtarget to select the Board implementation (like
A1x/XBurst/AU1x00/RT288x), or
a mix of both.

Is there a official definition when to use what?
The difference is not obvious to me.

-- 
Mit freundlichen Grüßen / Best regards

Claudio Thomas
Dipl.-Ing. der technischen Informatik (M.Sc.)

Leitung IT / Head of IT
Tel: +49 (0)2773 7444-137 
Fax: +49 (0)2773 7444-3137
Homepage: http://www.xmodus-systems.de
E-Mail: c...@xmodus-systems.de
GPG: http://xmodus-systems.de/gpg/ct
   4096R/22EC88BC; FP=2962 C442 BC49 21BB 5931  95A0 134A 0921 22EC 88BC
__
 
Xmodus Systems GmbH
Firmensitz: Reiherstrasse 2, D-35708 Haiger
Registergericht: Amtsgericht Wetzlar, HRB 6310
Geschäftsführer: Adrian F. Gog
__
 
Diese E-Mail und eventuelle Anhänge können vertrauliche Informationen 
enthalten. Wenn Sie nicht der beabsichtigte Empfänger sind, 
benachrichtigen Sie bitte unverzüglich den Absender und löschen Sie 
diese E-Mail. Jegliche unbefugte Anfertigung von Kopien, Offenlegung 
oder Verteilung des enthaltenen Materials ist streng verboten.

This e-mail and its attachments, if any, may contain confidential 
and/or privileged information. If you are not the intended recipient
please notify the sender immediately and delete this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in 
this e-mail is strictly forbidden.
__
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] When to use Target Profile or Subtarget

2014-07-15 Thread Jo-Philipp Wich 
Hi.

Profiles influence image generation and package selection but share all
a common kernel.

Subtargets are used if a different kernel is required.

~ Jow



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] [PATCH v2 00/18] atheros: I/O cleanups

2014-07-15 Thread Karl Palsson 
On Tue, Jul 15, 2014 at 03:57:19AM +0400, Sergey Ryazanov wrote:
 Main goals of this series:
  * Simplify interface between arch code and SoC drivers
  * Simplify internal realization of arch code
  * Make code consistent with mainstream kernel rules and practice
 
 This series extensively tested with FON2202 (ar2315 based) and D-Link
 DWL-2100AP (ar2313 based), but tests are not done with AR2317/8 and
 AR5312, since I have no access to such boards now.

I've tested this on an ar2317 (Dragino MS12) and it all appears to be working 
as before.  It doesn't run into
any watchdog timeouts, ethernet works, wifi works, leds work, (as well as they 
do on a clean trunk build
anyway, this board has a different led setup to trunk itself) buttons work.

Is there anything more in particular you'd like tested?

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

Re: [OpenWrt-Devel] [PATCH v2 00/18] atheros: I/O cleanups

2014-07-15 Thread Jonas Gorski 
On Tue, Jul 15, 2014 at 1:57 AM, Sergey Ryazanov ryazanov@gmail.com wrote:
 Main goals of this series:
  * Simplify interface between arch code and SoC drivers
  * Simplify internal realization of arch code
  * Make code consistent with mainstream kernel rules and practice

 This series extensively tested with FON2202 (ar2315 based) and D-Link
 DWL-2100AP (ar2313 based), but tests are not done with AR2317/8 and
 AR5312, since I have no access to such boards now.

 Changes since v1:
  * Add missed patch 'atheros[ar2315-wdt]: update initialization'

 Sergey Ryazanov (18):
   atheros[ar2315-wdt]: update initialization
   atheros[ar2315-wdt]: rename config symbol
   atheros: use correct address space and pointer type for register
 access
   atheros[ar2315-wdt]: update interrupt handling
   atheros[ar2315-wdt]: update I/O handling
   atheros[ar231x-eth]: update MAC and PHY reset method
   atheros[ar231x-eth]: move driver to atheros subdirectory
   atheros: pass UART IRQ number via function argument
   atheros: move AR2315 misc IRQ dispatching to separate function
   atheros: rename some interrupt control handlers
   atheros: simplify AR2315 misc IRQ (un)masking
   atheros: use irq_set_chained_handler()
   atheros: simplify gpiolib realization
   atheros[ar231x-eth]: pass phys address of I/O memory via platform res
   atheros[ar231x-eth]: pass PHY I/O memory via device resources
   atheros[uart]: use 32-bit aligned I/O
   atheros[uart]: pass only physical I/O mem address to 8250 driver
   atheros: update macroses names

as a nitpick: for the subject, instead of atheros[foo]: it would be
better to use atheros: foo: for the subject; this is the canonical
version of providing subsystem tags. Git tends to strip everything in
brackets, so these can easily get lost.


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

[OpenWrt-Devel] [PATCH] brcm47xx: fix LEDs on WRT54GL 1.1

2014-07-15 Thread Rafał Miłecki 
Ticket: #17062
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
 ...-BCM47XX-Devices-database-update-for-3.17.patch | 34 +++---
 ...-BCM47XX-Devices-database-update-for-3.17.patch | 34 +++---
 2 files changed, 60 insertions(+), 8 deletions(-)

diff --git 
a/target/linux/brcm47xx/patches-3.10/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
 
b/target/linux/brcm47xx/patches-3.10/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
index aa3e7ac..db965b1 100644
--- 
a/target/linux/brcm47xx/patches-3.10/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
+++ 
b/target/linux/brcm47xx/patches-3.10/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
@@ -38,7 +38,24 @@
BCM47XX_GPIO_LED(7, amber, wps, 0, LEDS_GPIO_DEFSTATE_OFF),
BCM47XX_GPIO_LED(8, blue, wps, 0, LEDS_GPIO_DEFSTATE_OFF),
  };
-@@ -333,11 +342,10 @@ bcm47xx_leds_linksys_wrt610nv2[] __initc
+@@ -314,6 +323,16 @@ bcm47xx_leds_linksys_wrt54g_type_0101[]
+   BCM47XX_GPIO_LED(7, green, dmz, 1, LEDS_GPIO_DEFSTATE_OFF),
+ };
+ 
++/* Verified on: WRT54GL V1.1 */
++static const struct gpio_led
++bcm47xx_leds_linksys_wrt54g_type_0467[] __initconst = {
++  BCM47XX_GPIO_LED(0, green, wlan, 1, LEDS_GPIO_DEFSTATE_OFF),
++  BCM47XX_GPIO_LED(1, green, power, 0, LEDS_GPIO_DEFSTATE_ON),
++  BCM47XX_GPIO_LED(2, white, wps, 1, LEDS_GPIO_DEFSTATE_OFF),
++  BCM47XX_GPIO_LED(3, orange, wps, 1, LEDS_GPIO_DEFSTATE_OFF),
++  BCM47XX_GPIO_LED(7, green, dmz, 1, LEDS_GPIO_DEFSTATE_OFF),
++};
++
+ static const struct gpio_led
+ bcm47xx_leds_linksys_wrt610nv1[] __initconst = {
+   BCM47XX_GPIO_LED(0, unk, usb,  1, LEDS_GPIO_DEFSTATE_OFF),
+@@ -333,11 +352,10 @@ bcm47xx_leds_linksys_wrt610nv2[] __initc
  
  static const struct gpio_led
  bcm47xx_leds_linksys_wrtsl54gs[] __initconst = {
@@ -54,7 +71,7 @@
  };
  
  /* Motorola */
-@@ -385,6 +393,15 @@ bcm47xx_leds_netgear_wndr4500v1[] __init
+@@ -385,6 +403,15 @@ bcm47xx_leds_netgear_wndr4500v1[] __init
  };
  
  static const struct gpio_led
@@ -70,7 +87,7 @@
  bcm47xx_leds_netgear_wnr834bv2[] __initconst = {
BCM47XX_GPIO_LED(2, green, power, 0, LEDS_GPIO_DEFSTATE_ON),
BCM47XX_GPIO_LED(3, amber, power, 0, LEDS_GPIO_DEFSTATE_OFF),
-@@ -425,6 +442,9 @@ void __init bcm47xx_leds_register(void)
+@@ -425,6 +452,9 @@ void __init bcm47xx_leds_register(void)
case BCM47XX_BOARD_ASUS_RTN12:
bcm47xx_set_pdata(bcm47xx_leds_asus_rtn12);
break;
@@ -80,7 +97,16 @@
case BCM47XX_BOARD_ASUS_RTN16:
bcm47xx_set_pdata(bcm47xx_leds_asus_rtn16);
break;
-@@ -582,6 +602,9 @@ void __init bcm47xx_leds_register(void)
+@@ -553,6 +583,8 @@ void __init bcm47xx_leds_register(void)
+   bcm47xx_set_pdata(bcm47xx_leds_linksys_wrt54g_type_0101);
+   break;
+   case BCM47XX_BOARD_LINKSYS_WRT54G_TYPE_0467:
++  bcm47xx_set_pdata(bcm47xx_leds_linksys_wrt54g_type_0467);
++  break;
+   case BCM47XX_BOARD_LINKSYS_WRT54G_TYPE_0708:
+   bcm47xx_set_pdata(bcm47xx_leds_linksys_wrt54g_generic);
+   break;
+@@ -582,6 +614,9 @@ void __init bcm47xx_leds_register(void)
case BCM47XX_BOARD_NETGEAR_WNDR4500V1:
bcm47xx_set_pdata(bcm47xx_leds_netgear_wndr4500v1);
break;
diff --git 
a/target/linux/brcm47xx/patches-3.14/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
 
b/target/linux/brcm47xx/patches-3.14/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
index aa3e7ac..db965b1 100644
--- 
a/target/linux/brcm47xx/patches-3.14/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
+++ 
b/target/linux/brcm47xx/patches-3.14/146-MIPS-BCM47XX-Devices-database-update-for-3.17.patch
@@ -38,7 +38,24 @@
BCM47XX_GPIO_LED(7, amber, wps, 0, LEDS_GPIO_DEFSTATE_OFF),
BCM47XX_GPIO_LED(8, blue, wps, 0, LEDS_GPIO_DEFSTATE_OFF),
  };
-@@ -333,11 +342,10 @@ bcm47xx_leds_linksys_wrt610nv2[] __initc
+@@ -314,6 +323,16 @@ bcm47xx_leds_linksys_wrt54g_type_0101[]
+   BCM47XX_GPIO_LED(7, green, dmz, 1, LEDS_GPIO_DEFSTATE_OFF),
+ };
+ 
++/* Verified on: WRT54GL V1.1 */
++static const struct gpio_led
++bcm47xx_leds_linksys_wrt54g_type_0467[] __initconst = {
++  BCM47XX_GPIO_LED(0, green, wlan, 1, LEDS_GPIO_DEFSTATE_OFF),
++  BCM47XX_GPIO_LED(1, green, power, 0, LEDS_GPIO_DEFSTATE_ON),
++  BCM47XX_GPIO_LED(2, white, wps, 1, LEDS_GPIO_DEFSTATE_OFF),
++  BCM47XX_GPIO_LED(3, orange, wps, 1, LEDS_GPIO_DEFSTATE_OFF),
++  BCM47XX_GPIO_LED(7, green, dmz, 1, LEDS_GPIO_DEFSTATE_OFF),
++};
++
+ static const struct gpio_led
+ bcm47xx_leds_linksys_wrt610nv1[] __initconst = {
+   BCM47XX_GPIO_LED(0, unk, usb,  1, LEDS_GPIO_DEFSTATE_OFF),
+@@ -333,11 +352,10 @@ bcm47xx_leds_linksys_wrt610nv2[] __initc
  
  static const struct gpio_led
  bcm47xx_leds_linksys_wrtsl54gs[] __initconst = {
@@ -54,7 +71,7 @@
  };
  
  /* Motorola */
-@@ -385,6 +393,15 @@

Re: [OpenWrt-Devel] [PATCH v2 00/18] atheros: I/O cleanups

2014-07-15 Thread Sergey Ryazanov 
2014-07-15 17:53 GMT+04:00 Jonas Gorski j...@openwrt.org:
 On Tue, Jul 15, 2014 at 1:57 AM, Sergey Ryazanov ryazanov@gmail.com 
 wrote:
 Main goals of this series:
  * Simplify interface between arch code and SoC drivers
  * Simplify internal realization of arch code
  * Make code consistent with mainstream kernel rules and practice

 This series extensively tested with FON2202 (ar2315 based) and D-Link
 DWL-2100AP (ar2313 based), but tests are not done with AR2317/8 and
 AR5312, since I have no access to such boards now.

 Changes since v1:
  * Add missed patch 'atheros[ar2315-wdt]: update initialization'

 Sergey Ryazanov (18):
   atheros[ar2315-wdt]: update initialization
   atheros[ar2315-wdt]: rename config symbol
   atheros: use correct address space and pointer type for register
 access
   atheros[ar2315-wdt]: update interrupt handling
   atheros[ar2315-wdt]: update I/O handling
   atheros[ar231x-eth]: update MAC and PHY reset method
   atheros[ar231x-eth]: move driver to atheros subdirectory
   atheros: pass UART IRQ number via function argument
   atheros: move AR2315 misc IRQ dispatching to separate function
   atheros: rename some interrupt control handlers
   atheros: simplify AR2315 misc IRQ (un)masking
   atheros: use irq_set_chained_handler()
   atheros: simplify gpiolib realization
   atheros[ar231x-eth]: pass phys address of I/O memory via platform res
   atheros[ar231x-eth]: pass PHY I/O memory via device resources
   atheros[uart]: use 32-bit aligned I/O
   atheros[uart]: pass only physical I/O mem address to 8250 driver
   atheros: update macroses names

 as a nitpick: for the subject, instead of atheros[foo]: it would be
 better to use atheros: foo: for the subject; this is the canonical
 version of providing subsystem tags. Git tends to strip everything in
 brackets, so these can easily get lost.

Thank you for this hint. I really never hear about this git feature.


 Jonas

-- 
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 v2 00/18] atheros: I/O cleanups

2014-07-15 Thread Sergey Ryazanov 
2014-07-15 17:50 GMT+04:00 Karl Palsson ka...@tweak.net.au:
 On Tue, Jul 15, 2014 at 03:57:19AM +0400, Sergey Ryazanov wrote:
 Main goals of this series:
  * Simplify interface between arch code and SoC drivers
  * Simplify internal realization of arch code
  * Make code consistent with mainstream kernel rules and practice

 This series extensively tested with FON2202 (ar2315 based) and D-Link
 DWL-2100AP (ar2313 based), but tests are not done with AR2317/8 and
 AR5312, since I have no access to such boards now.

 I've tested this on an ar2317 (Dragino MS12) and it all appears to be working 
 as before.  It doesn't run into
 any watchdog timeouts, ethernet works, wifi works, leds work, (as well as 
 they do on a clean trunk build
 anyway, this board has a different led setup to trunk itself) buttons work.

 Is there anything more in particular you'd like tested?

Seems that your tests cover all changes. Thanks!

 Sincerely,
 Karl Palsson


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

Re: [OpenWrt-Devel] Barrier Breaker 14.07-rc1

2014-07-15 Thread Jonathan Bennett 
On Mon, Jul 14, 2014 at 4:12 AM, John Crispin j...@phrozen.org wrote:


 The OpenWrt developers are proud to announce the first release
 candidate of OpenWrt Barrier Breaker.
   ___ __
  |   |.-.-.-.|  |  |  |..|  |_
  |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
  |___||   __|_|__|__||||__|  ||
   |__| W I R E L E S S   F R E E D O M
  -
  BARRIER BREAKER (14.07 RC1)
  -
   * 1/2 oz Galliano Pour all ingredients into
   * 4 oz cold Coffeean irish coffee mug filled
   * 1 1/2 oz Dark Rum   with crushed ice. Stir.
   * 2 tsp. Creme de Cacao
  -

 http://downloads.openwrt.org/barrier_breaker/14.07-rc1/

 ** Highlights since Attitude Adjustment **
 Default configuration and images

 * Linux kernel updated to version 3.10

 * Procd: new preinit, init, hotplug and event system written in C

 * Native IPv6-support
 - RA  DHCPv6+PD client and server
 - Local prefix allocation  source-restricted routes
   (multihoming)

 * Filesystem improvements
 - Added support for sysupgrade on NAND-flash
 - Added support for filesystem snapshot and rollback
 - Rewritten mounting system in C for rootfs and block devices

 * UCI configuration improvements
 - Support for testing configuration and rollback to working
   last working state
 - Unified change trigger system to restart services on-demand
 - Added a data validation layer

 * Networking improvements
 - Netifd now handles setup and configuration reload of
   wireless interfaces
 - Added reworked event support to allow obsoleting network
   hotplug-scripts
 - Added support for dynamic firewall rules and zones
 - Added support for transparent multicast to unicast
   translation for bridges
 - Various other fixes and improvements


 Additional highlights selectable in the package feeds or SDK
 * Extended IPv6-support
 - Added DS-Lite support and improved 6to4, 6in4 and 6rd-support
 - Experimental support for Lightweight 4over6, MAP-E and MAP-T
 - Draft-support for self-managing home networks (HNCP)

 * rpcd: new JSONRPC over HTTP-frontend for remote access to ubus

 * mdns: new lightweight mdns daemon (work in progress)

 * Initial support for the musl C standard library

 * Support for QMI-based 3g/4g modems

 * Support for DNSSEC validation

 * Added architecture for package signing and SHA256 hashing

 * ... and many more cool things

 Package feed reorganization
 For quite a while already we are not very satisfied with the quality
 of the packages-feed. To address this, we decided to do a fresh start
 on GitHub. The new feed https://github.com/openwrt/packages should be
 used from now on and package maintainers are asked to move their
 packages there. For the final release we will still build the old
 packages feed but it will be necessary to enable it manually in the
 opkg package list to be usable. All current feeds should not have any
 dependencies on the old.packages feed. Currently a few packages still
 fail, mainly due to these cross feed dependencies. We will contact the
 respective maintainers to help resolve these issues for RC2.


 New build servers
 We would like to express our gratitude to Imagination Technology for
 funding the 2 build servers that we used for the release.


 Whats next ?
 We aim at releasing Chaos Calmer (CC) before the end of the year. The
 CC release will use 3.14 or a newer LTS kernel as baseline.


 Have fun!
 The OpenWrt developer team
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Is Barrier Breaker actually a branched release, or is this more of a trunk
snapshot?

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

Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

2014-07-15 Thread Aaron Z 
- Original Message -
On Monday, July 14, 2014 5:36:09 PM Benjamin Cama ben...@dolka.fr wrote:
 Hi everyone,
 
 Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :
  On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote:
   Hi Baptiste,
   
   in general our current firewalling approach is to keep defaults
   for IPv4 and
   IPv6 relatively close (not considering NAT here of course).
  
  Could you detail the reasoning behind this approach?  Don't
  confuse the user?
  
  I'd rather have Don't bother the user: things should generally
  just
  work, without having to configure anything (in this case, port
  forwarding).  But there is an obvious tradeoff with security.
 
 I agree with Baptiste here. There is no equivalent in IPv4 of “global
 reachability” by default with the NATs we have today, so we can't
 have
 the same defaults. Global reachability is how IP in general was meant
 to
 be; please, do not make it broken again.
As I understand it, this is NOT adding NAT, but (by default) blocking 
unsolicited incoming connections from the outside world to devices on the 
internal network (which dont necessarily need to be accessible from the outside 
world). That is the whole point in using a firewall is it not? To keep people 
out of where they shouldn't be.


   Opening up the IPv6 firewall by default would be unexpected and I
   don't
   really like the approach for that matter and honestly I don't
   trust
   client devices that much.
  
  At least opening UDP ports  1024 seems pretty reasonable, and
  covers most
  use-cases regarding VoIP and video.  But it does indeed depart from
  the
  IPv4 case (not sure if it is such a bad idea though).
 
 This looks like a good compromise to me. Knowledgeable users can
 disable
 the firewall for needed hosts, while for others this “just work”. PCP
 may be coming one day, but it's still not there yet, so we need not
 to
 break the default configuration while waiting for it.
Opening access from the outside to the inside as a default rule goes against 
the principle of least privilege on which firewall rules are generally 
predicated.
As I understand it, if a device on the inside of the network initiates the 
connection to a device on the outside (say from a VOIP phone to a VOIP server), 
return connections from the server are allowed. What gets blocked are 
unsolicited connections from the outside which are generally unneeded (and can 
be a security risk) unless one is running a server (in which case, the users 
should know how to open ports on their firewall).

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

[OpenWrt-Devel] Barrier Breaker on au1000 (MTX-1)

2014-07-15 Thread Bruno Randolf 
Hello,

I needed to update the kernel version to 3.10.44 to compile Barrier
Breaker for au1000 (MTX-1):

diff --git a/target/linux/au1000/Makefile b/target/linux/au1000/Makefile

index 2f9c24d..5fb4a43 100644

--- a/target/linux/au1000/Makefile
+++ b/target/linux/au1000/Makefile
@@ -13,7 +13,7 @@ FEATURES:=squashfs usb pci
 SUBTARGETS=au1500 au1550
 MAINTAINER:=Florian Fainelli flor...@openwrt.org

-LINUX_VERSION:=3.6.11
+LINUX_VERSION:=3.10.44

 include $(INCLUDE_DIR)/target.mk
 DEFAULT_PACKAGES += wpad-mini yamonenv

With this change everything works fine, apart from that the htmode
option was empty for ath5k devices, but that's a different story.

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

Re: [OpenWrt-Devel] [PATCH] ramips: soc wmac eeprom cleanup

2014-07-15 Thread John Crispin 
Hi,

lovely, works for me on the 6 boards that i tested. will merge it in a
sec.

i will look into the fixme bits.

John

On 14/07/2014 23:13, Roman Yeryomin wrote:
 Move eeprom extraction from scripts to dts files. Additionally 
 there are few other changes like: - whitespace fixes - add 
 partition labels where needed - BR6524N board doesn't exist (lost 
 in translation?) - fix Edimax 3g-6200nl model - add wmac eeprom to 
 dts for Asus RT-N14U board
 
 Compile tested all subtargets and their profiles. Run tested on: - 
 Asus RT-N15 - Asus RT-N14U - Buffalo WHR-600D - Argus ATP52B - 
 Sparklan WCR-150GN
 
 Few problems noted: - many boards didn't have wmac eeprom 
 information defined at all - several boards don't have any 
 patitions defined (see FIXME comments in dts)
 
 Signed-off-by: Roman Yeryomin ro...@advem.lv --- 
 .../etc/hotplug.d/firmware/10-rt2x00-eeprom| 106 
 + target/linux/ramips/base-files/lib/ramips.sh 
 |   3 - target/linux/ramips/dts/3G-6200N.dts   |   4 +
  target/linux/ramips/dts/3G-6200NL.dts  |   8 +- 
 target/linux/ramips/dts/3G300M.dts |   4 + 
 target/linux/ramips/dts/AIR3GII.dts|   4 + 
 target/linux/ramips/dts/ALL0239-3G.dts |   4 + 
 target/linux/ramips/dts/ALL0256N-4M.dts|   4 + 
 target/linux/ramips/dts/ALL0256N-8M.dts|   4 + 
 target/linux/ramips/dts/ALL5002.dts|   4 + 
 target/linux/ramips/dts/ALL5003.dts|   4 + 
 target/linux/ramips/dts/ARGUS_ATP52B.dts   |   4 + 
 target/linux/ramips/dts/ASL26555-16M.dts   |   6 +- 
 target/linux/ramips/dts/ASL26555-8M.dts|   5 + 
 target/linux/ramips/dts/AWAPN2403.dts  |   4 + 
 target/linux/ramips/dts/AWM002-EVB-4M.dts  |   4 + 
 target/linux/ramips/dts/AWM002-EVB-8M.dts  |   4 + 
 target/linux/ramips/dts/BC2.dts|   4 + 
 target/linux/ramips/dts/BR-6425.dts|   4 + 
 target/linux/ramips/dts/BR-6475ND.dts  |   4 + 
 target/linux/ramips/dts/BROADWAY.dts   |   4 + 
 target/linux/ramips/dts/CARAMBOLA.dts  |   4 + 
 target/linux/ramips/dts/CY-SWR1100.dts |   1 + 
 target/linux/ramips/dts/D105.dts   |   4 + 
 target/linux/ramips/dts/DAP-1350.dts   |   6 +- 
 target/linux/ramips/dts/DCS-930.dts|   4 + 
 target/linux/ramips/dts/DIR-300-B1.dts |   6 +- 
 target/linux/ramips/dts/DIR-300-B7.dts |   7 +- 
 target/linux/ramips/dts/DIR-320-B1.dts |   4 + 
 target/linux/ramips/dts/DIR-600-B1.dts |   6 +- 
 target/linux/ramips/dts/DIR-600-B2.dts |   6 +- 
 target/linux/ramips/dts/DIR-610-A1.dts |   2 +- 
 target/linux/ramips/dts/DIR-615-D.dts  |   6 +- 
 target/linux/ramips/dts/DIR-615-H1.dts |   4 + 
 target/linux/ramips/dts/DIR-620-A1.dts |   4 + 
 target/linux/ramips/dts/DIR-620-D1.dts |   4 + 
 target/linux/ramips/dts/DIR-645.dts|   1 + 
 target/linux/ramips/dts/ESR-9753.dts   |   4 + 
 target/linux/ramips/dts/F5D8235_V1.dts |   6 +- 
 target/linux/ramips/dts/F5D8235_V2.dts |   6 +- 
 target/linux/ramips/dts/F7C027.dts |   4 + 
 target/linux/ramips/dts/FONERA20N.dts  |   4 + 
 target/linux/ramips/dts/FREESTATION5.dts   |   4 + 
 target/linux/ramips/dts/HG255D.dts |   4 + 
 target/linux/ramips/dts/HW550-3G.dts   |   4 + 
 target/linux/ramips/dts/MOFI3500-3GN.dts   |   1 + 
 target/linux/ramips/dts/MPRA1.dts  |   4 + 
 target/linux/ramips/dts/MPRA2.dts  |   4 + 
 target/linux/ramips/dts/MZK-750DHP.dts |   4 + 
 target/linux/ramips/dts/MZK-W300NH2.dts|   4 + 
 target/linux/ramips/dts/NBG-419N.dts   |   4 + 
 target/linux/ramips/dts/NCS601W.dts|   4 + 
 target/linux/ramips/dts/NW718.dts  |   4 + 
 target/linux/ramips/dts/OMNI-EMB-HPM.dts   |   4 + 
 target/linux/ramips/dts/OMNI-EMB.dts   |   4 + 
 target/linux/ramips/dts/PSR-680W.dts   |   4 + 
 target/linux/ramips/dts/PWH2004.dts|   4 + 
 target/linux/ramips/dts/RT-G32-B1.dts  |   8 +- 
 target/linux/ramips/dts/RT-N10-PLUS.dts|   6 +- 
 target/linux/ramips/dts/RT-N13U.dts|   4 + 
 target/linux/ramips/dts/RT-N14U.dts|   4 + 
 target/linux/ramips/dts/RT-N15.dts |   4 + 
 target/linux/ramips/dts/RTN56U.dts |   2 +- 
 target/linux/ramips/dts/RUT5XX.dts |   4 + 
 target/linux/ramips/dts/SL-R7205.dts   |   4 + 
 target/linux/ramips/dts/UR-326N4G.dts  |   4 + 
 target/linux/ramips/dts/UR-336UN.dts   |  10 +- 
 target/linux/ramips/dts/V11STFE.dts

Re: [OpenWrt-Devel] [PATCH] ar71xx: update Carambola2 platform data

2014-07-15 Thread Felix Fietkau 
On 2014-07-15 12:53, Mantas Pucka wrote:
 Sorry, change list got cut off in previous mail:
 
 ar71xx: update Carambola2 platform data
 
   * Remove button info on GPIO12, there is no button there.
   * Remove nvram mtd partition, as it's not used for anything, saves 
 64k for user data
Your patch is mangled by broken line wrapping. Please fix and resend
with the change list included in the message.

Thanks,

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

[OpenWrt-Devel] Sysupgrade to Barrier Breaker on au1000 (MTX-1)

2014-07-15 Thread Bruno Randolf 
Another problem I noted when upgrading from AA to BB on MTX-1:

# sysupgrade -n /tmp/openwrt-au1000-au1500-jffs2-128k-sysupgrade.bin
tar: openwrt-au1000-au1500-jffs2-128k.fs: not found in archive
Invalid image contents
Image check 'platform_check_image' failed.

I needed to change in /lib/upgrade/platform.sh:
ROOTFS_IMG=openwrt-au1000-au1500-root.fs

In AA the ROOTFS image was called differently, the name in BB makes more
sense, but how could we provide a good upgrade path from AA to BB?

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

Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

2014-07-15 Thread Fernando Frediani 

Fully agree with Aaron's comments below.

Regards,

Fernando

On 15/07/2014 16:45, Aaron Z wrote:

- Original Message -
On Monday, July 14, 2014 5:36:09 PM Benjamin Cama ben...@dolka.fr wrote:

Hi everyone,

Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :

On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote:

Hi Baptiste,

in general our current firewalling approach is to keep defaults
for IPv4 and
IPv6 relatively close (not considering NAT here of course).

Could you detail the reasoning behind this approach?  Don't
confuse the user?

I'd rather have Don't bother the user: things should generally
just
work, without having to configure anything (in this case, port
forwarding).  But there is an obvious tradeoff with security.

I agree with Baptiste here. There is no equivalent in IPv4 of “global
reachability” by default with the NATs we have today, so we can't
have
the same defaults. Global reachability is how IP in general was meant
to
be; please, do not make it broken again.

As I understand it, this is NOT adding NAT, but (by default) blocking 
unsolicited incoming connections from the outside world to devices on the 
internal network (which dont necessarily need to be accessible from the outside 
world). That is the whole point in using a firewall is it not? To keep people 
out of where they shouldn't be.



Opening up the IPv6 firewall by default would be unexpected and I
don't
really like the approach for that matter and honestly I don't
trust
client devices that much.

At least opening UDP ports  1024 seems pretty reasonable, and
covers most
use-cases regarding VoIP and video.  But it does indeed depart from
the
IPv4 case (not sure if it is such a bad idea though).

This looks like a good compromise to me. Knowledgeable users can
disable
the firewall for needed hosts, while for others this “just work”. PCP
may be coming one day, but it's still not there yet, so we need not
to
break the default configuration while waiting for it.

Opening access from the outside to the inside as a default rule goes against the 
principle of least privilege on which firewall rules are generally predicated.
As I understand it, if a device on the inside of the network initiates the 
connection to a device on the outside (say from a VOIP phone to a VOIP server), 
return connections from the server are allowed. What gets blocked are 
unsolicited connections from the outside which are generally unneeded (and can 
be a security risk) unless one is running a server (in which case, the users 
should know how to open ports on their firewall).

Aaron Z
___
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] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

2014-07-15 Thread Benjamin Cama 
Le mardi 15 juillet 2014 à 11:45 -0400, Aaron Z a écrit :
 - Original Message -
 On Monday, July 14, 2014 5:36:09 PM Benjamin Cama ben...@dolka.fr wrote:
  Hi everyone,
  
  Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :
   I'd rather have Don't bother the user: things should generally
   just
   work, without having to configure anything (in this case, port
   forwarding).  But there is an obvious tradeoff with security.
  
  I agree with Baptiste here. There is no equivalent in IPv4 of “global
  reachability” by default with the NATs we have today, so we can't
  have
  the same defaults. Global reachability is how IP in general was meant
  to
  be; please, do not make it broken again.
 As I understand it, this is NOT adding NAT, but (by default) blocking
 unsolicited incoming connections from the outside world to devices on
 the internal network (which dont necessarily need to be accessible
 from the outside world).

This thread is about choosing a sane default. Blocking by default means
you can't have VoIP or P2P working out of the box. This was tricky with
IPv4+NAT as it involves some trickery and software support (see UPnP and
the like), but IPv6 offers the possibility to have it work without any
supplemental development effort!

When you say that devices don't “necessarily” need to be accessible, you
already made a choice that is impossible to change back for 99.99% of
people (which don't know how to tune a firewall).

 That is the whole point in using a firewall is it not? To keep people
 out of where they shouldn't be.

Well, you can configure your “firewall” as it pleases you to block
whatever you want, but the one in OpenWRT is quite “open” by default, as
much as permit IPv4 (which is, only outbound connections are allowed;
inbound connections are not possible “by design” by default because of
NAT).

Opening up the IPv6 firewall by default would be unexpected and I
don't
really like the approach for that matter and honestly I don't
trust
client devices that much.
   
   At least opening UDP ports  1024 seems pretty reasonable, and
   covers most
   use-cases regarding VoIP and video.  But it does indeed depart from
   the
   IPv4 case (not sure if it is such a bad idea though).
  
  This looks like a good compromise to me. Knowledgeable users can
  disable
  the firewall for needed hosts, while for others this “just work”. PCP
  may be coming one day, but it's still not there yet, so we need not
  to
  break the default configuration while waiting for it.
 Opening access from the outside to the inside as a default rule goes
 against the principle of least privilege on which firewall rules are
 generally predicated.

I do not understand what the principle of least privilege has to do
here. “Forbidden by default” is not about privileges.

 As I understand it, if a device on the inside of the network initiates
 the connection to a device on the outside (say from a VOIP phone to a
 VOIP server), return connections from the server are allowed.

Yes, by looking at it from a very client-inside and server-outside (and
TCP and state-tracking) view. That is a lot of presuppositions. This
way, you can call a “server”, but nobody can call you.

 What gets blocked are unsolicited connections from the outside which
 are generally unneeded (and can be a security risk)

The “generally unneeded” and “security risk” assumptions are very
biased, to me. I won't reiterate the general argument about running only
services that one need, but what we are talking about here is finding a
compromise between reachability and security. Blocking services bound on
system ports (1024, see http://tools.ietf.org/html/rfc6335#section-6)
only seems like a good compromise to me.

A general principle is that a service should not be bound on a globally
reachable address if it is not meant to be globally accessible. Of
course two layers of security are better and to apply some global
network rules, we have firewalls, but this should not hinder the nice
capability of IP to have global reachability by default by design.

 unless one is running a server (in which case, the users should know
 how to open ports on their firewall).

Well, it depends on what is a “server” to you. Is being able to receive
a phone call directly from your correspondent a “server” use to you?
Technically, it kind of is (we don't even use the word “server” for it,
just “peer”). Should user of such a feature (which is just one example
among many) be savvy enough to be able to open ports on his firewall? I
don't think so. Same goes for P2P, personal file exchange through
diverse protocols, general “server” setup without explicit port-opening,
etc.

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

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-15 Thread Nikolai Zhubr 

15.07.2014 12:04, Nikolai Zhubr:

15.07.2014 1:42, Jonas Gorski:
[...]

or
bw32(bp, B44_RXMAXLEN, bp-dev-mtu + ETH_HLEN + 8) ?


This is the right one; mtu (the payload) + ETH_HLEN (14 bytes) + 8
(4 bytes for vlan tag, probably 4 extra bytes for custom header
optionally used by broadcom switches)


Ok, tested this. Unfortunately it's still panicing under load (and
seemingly this change made no difference whatsoever):


And I've performed yet another experiment. If I insert an additional 
router (running also openwrt but atheros-based) between this WL-500W and 
uplink (with the idea to filter out any strange and bogus incoming 
packets) and redo the same test, I get no panic but instead a silent 
spontaneous reboot in a few minutes after reaching 30mbit traffic. I'll 
retest this more carefully later, and meanwhile I think:


1. Apparently some (bogus?) packets ocasionally coming from uplink still 
confuse b44 driver and cause panics regardless of my B44_RXMAXLEN 
correction.


2. Silent reboot might probably indicate hardware problem like 
overheating. Although I have its case open and I touched its chips, 
well, they were acceptably warm I think. Another point is that CPU 
performance limits routing capability of this device (when using openwrt 
at least) somewhere around 33mbit, so getting close to continuous 100% 
CPU usage might probably lead to watchdog trigger? (Just a random 
speculation)



Thank you.
Nikolai




[ 271.21] [ cut here ]
[ 271.22] WARNING: at net/core/dev.c:2194
skb_warn_bad_offload+0xc0/0xe8()
[ 271.22] b44: caps=(0x4000, 0x) len=377
data_len=0 gso_size=57048 gso_type=32506 ip_summed=0
[ 271.24] Modules linked in: pppoe ppp_async iptable_nat b43legacy
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[ 271.30] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.44 #2
[ 271.30] Stack :     8030d552
0036 818201d0 0008
80272688 802bf23b 0003 8030cd00 818201d0 0008 802bb6e4 
802bb6dc 8001c204 0003 80019bc4 80299520 0008 80273f28 8182bc5c
       
       8182bbe8
...
[ 271.34] Call Trace:
[ 271.34] [80010ca0] show_stack+0x48/0x70
[ 271.35] [80019cc0] warn_slowpath_common+0x78/0xa8
[ 271.35] [80019d1c] warn_slowpath_fmt+0x2c/0x38
[ 271.36] [801b2d10] skb_warn_bad_offload+0xc0/0xe8
[ 271.36] [801b68c4] __skb_gso_segment+0x50/0xec
[ 271.37] [801de5bc] ip_forward_finish+0x108/0x1bc
[ 271.37] [801b3da0] __netif_receive_skb_core+0x46c/0x52c
[ 271.38] [81ad41d4] 0x81ad41d4
[ 271.38]
[ 271.38] ---[ end trace b4f0aa7175b12bf7 ]---
[ 271.39] Unhandled kernel unaligned access[#1]:
[ 271.39] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 3.10.44 #2
[ 271.39] task: 81820028 ti: 8182a000 task.ti: 8182a000
[ 271.39] $ 0 :  0001 81696a48 0028
[ 271.39] $ 4 : 2d37d9ee  7088 
[ 271.39] $ 8 : 002d 35373137 62323162 5d203766
[ 271.39] $12 :  03bf  bc00
[ 271.39] $16 : 80e7fec0 0001 0001 0014
[ 271.39] $20 :  0008 802bb6e4 
[ 271.39] $24 : 0003 80150bcc
[ 271.39] $28 : 8182a000 8182bd28 802bb6dc 801ab22c
[ 271.39] Hi : 
[ 271.39] Lo : 0083
[ 271.39] epc : 80064440 put_page+0x0/0x4c
[ 271.39] Tainted: G W
[ 271.39] ra : 801ab22c skb_release_data+0xc4/0x118
[ 271.39] Status: 1000b803 KERNEL EXL IE
[ 271.39] Cause : 00800010
[ 271.39] BadVA : 2d37d9ee
[ 271.39] PrId : 00029006 (Broadcom BMIPS3300)
[ 271.39] Modules linked in: pppoe ppp_async iptable_nat b43legacy
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[ 271.39] Process ksoftirqd/0 (pid: 3,

[OpenWrt-Devel] Compiling kernel modules for Openwrt

2014-07-15 Thread Methos 
Hi,

I am trying to compile kernel module kmod-ipt-tee.
I enabled it using make menuconfig

Now I see:

# grep kmod-ipt-tee .config
CONFIG_PACKAGE_kmod-ipt-tee=m

But when I execute:
make package/kernel/{compile,install} V=99

I see:
WARNING: kmod-ipt-tee is not available in the kernel config


After some searching, I found following:
https://forum.openwrt.org/viewtopic.php?id=33112

It tells to add kernel module option in 
target/linux/generic/config-$version

But, for kernel modules that are getting compiled in my build setup, I do
not see them present in target/linux/generic/config-$version

What should I do to get this module compiling?

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

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-15 Thread Nikolai Zhubr 

15.07.2014 23:26, Nikolai Zhubr:
[...]

And I've performed yet another experiment. If I insert an additional
router (running also openwrt but atheros-based) between this WL-500W and
uplink (with the idea to filter out any strange and bogus incoming
packets) and redo the same test, I get no panic but instead a silent
spontaneous reboot in a few minutes after reaching 30mbit traffic. I'll


Here is a slightly different panic, although also involving 
netif_receive_skb_core (And this is still with additional openwrt router 
inserted before uplink):


[  900.72] CPU 0 Unable to handle kernel paging request at virtual 
address 0004, epc == 80119aa0, ra == 8011b2e8

[  900.72] Oops[#1]:
[  900.72] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.44 #2
[  900.72] task: 81820028 ti: 8182a000 task.ti: 8182a000
[  900.72] $ 0   :  10003800 80f29a48 
[  900.72] $ 4   : 802be1a0 802bdc1c  fffc
[  900.72] $ 8   : 0384 2b82ea80 00989680 
[  900.72] $12   : 0384 3c87  
[  900.72] $16   : 802be1a0 802bdc1c 802bdc40 7fff
[  900.72] $20   : 0384  2aea8de9 
[  900.72] $24   :  80016dc0
[  900.72] $28   : 8182a000 8182bb50 0384 8011b2e8
[  900.72] Hi: 
[  900.72] Lo: 3c87
[  900.72] epc   : 80119aa0 rb_insert_color+0x2c/0x14c
[  900.72] Not tainted
[  900.72] ra: 8011b2e8 timerqueue_add+0xc0/0x118
[  900.72] Status: 10003802 KERNEL EXL
[  900.72] Cause : 0088
[  900.72] BadVA : 0004
[  900.72] PrId  : 00029006 (Broadcom BMIPS3300)
[  900.72] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[  900.72] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000, 
task=81820028, tls=)
[  900.72] Stack : 802bdc40 7fff 0384  802be1a0 
802bdc10 802bdc40 8003a144

  802be1a0 802c  802c 802c 802bdbe0 2aea8de9 
8003a9c8
   8182bc08 80c52220 80eb93a0 0001 0001 2aea8de9 
0384
  0003 2aea8de9 0384 80f122e4  0007 802c2870 

   80a169b5 802c 802765f4 80276608 80012d00 0001 
00014600
  ...
[  900.72] Call Trace:
[  900.72] [80119aa0] rb_insert_color+0x2c/0x14c
[  900.72] [8011b2e8] timerqueue_add+0xc0/0x118
[  900.72] [8003a144] __run_hrtimer.isra.26+0x7c/0xf8
[  900.72] [8003a9c8] hrtimer_interrupt+0x14c/0x3f4
[  900.72] [80012d00] c0_compare_interrupt+0x74/0xa0
[  900.72] [8005335c] handle_irq_event_percpu+0x64/0x1ec
[  900.72] [80055e60] handle_percpu_irq+0x54/0x84
[  900.72] [80052ce0] generic_handle_irq+0x28/0x44
[  900.72] [8000e24c] do_IRQ+0x1c/0x2c
[  900.72] [8000a3ec] plat_irq_dispatch+0x40/0xb8
[  900.72] [80001448] ret_from_irq+0x0/0x4
[  900.72] [80005590] __copy_user_common+0x248/0x2d8
[  900.72] [801a8830] skb_copy_ubufs+0xec/0x204
[  900.72] [801b3db0] __netif_receive_skb_core+0x47c/0x52c
[  900.72] [81ad41d4] 0x81ad41d4
[  900.72]
[  900.72]
Code: 30660001  14c00047   8c660004 10460016   
10c5    8cc8

[  900.72] ---[ end trace de6e4d131b0441ac ]---
[  900.72] Kernel panic - not syncing: Fatal exception in interrupt




retest this more carefully later, and meanwhile I think:

1. Apparently some (bogus?) packets ocasionally coming from uplink still
confuse b44 driver and cause panics regardless of my B44_RXMAXLEN
correction.

2. Silent reboot might probably indicate hardware problem like
overheating. Although I have its case open and I touched its chips,
well, they were acceptably warm I think. Another point is that CPU
performance limits routing capability of this device (when using openwrt
at least) somewhere around 33mbit, so getting close to continuous 100%
CPU usage might probably lead to watchdog trigger? (Just a random
speculation)


Thank you.
Nikolai




[ 271.21] [ cut here ]
[ 271.22] WARNING: at net/core/dev.c:2194
skb_warn_bad_offload+0xc0/0xe8()
[ 271.22] b44: caps=(0x4000, 0x) len=377
data_len=0 gso_size=57048 gso_type=32506 ip_summed=0
[ 271.24] Modules linked in: pppoe ppp_async iptable_nat b43legacy
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211

Re: [OpenWrt-Devel] Compiling kernel modules for Openwrt

2014-07-15 Thread Jonas Gorski 
On Tue, Jul 15, 2014 at 10:06 PM, Methos methos.old...@gmail.com wrote:
 Hi,

 I am trying to compile kernel module kmod-ipt-tee.
 I enabled it using make menuconfig

 Now I see:

 # grep kmod-ipt-tee .config
 CONFIG_PACKAGE_kmod-ipt-tee=m

 But when I execute:
 make package/kernel/{compile,install} V=99

 I see:
 WARNING: kmod-ipt-tee is not available in the kernel config


 After some searching, I found following:
 https://forum.openwrt.org/viewtopic.php?id=33112

 It tells to add kernel module option in
 target/linux/generic/config-$version

 But, for kernel modules that are getting compiled in my build setup, I do
 not see them present in target/linux/generic/config-$version

 What should I do to get this module compiling?

You need to call make target/linux/compile, this step actually
compiles the modules/.ko's. package/kernel/compile only packages them.



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

Re: [OpenWrt-Devel] Compiling kernel modules for Openwrt

2014-07-15 Thread Methos 
Thanks for the prompt response.
I tried to do that for a new package: kmod-ipt-condition
I see that it is enabled in .config as 'm'.

After that, I executed make target/linux/{compile,install}

After that, I executed make package/kernel/{clean,compile,install}

I see that file xt_condition.ko is created.

But still no kmod-ipt-condition.ipk

What last packaging step am I missing?




On Tue, Jul 15, 2014 at 4:39 PM, Jonas Gorski j...@openwrt.org wrote:

 On Tue, Jul 15, 2014 at 10:06 PM, Methos methos.old...@gmail.com wrote:
  Hi,
 
  I am trying to compile kernel module kmod-ipt-tee.
  I enabled it using make menuconfig
 
  Now I see:
 
  # grep kmod-ipt-tee .config
  CONFIG_PACKAGE_kmod-ipt-tee=m
 
  But when I execute:
  make package/kernel/{compile,install} V=99
 
  I see:
  WARNING: kmod-ipt-tee is not available in the kernel config
 
 
  After some searching, I found following:
  https://forum.openwrt.org/viewtopic.php?id=33112
 
  It tells to add kernel module option in
  target/linux/generic/config-$version
 
  But, for kernel modules that are getting compiled in my build setup, I do
  not see them present in target/linux/generic/config-$version
 
  What should I do to get this module compiling?

 You need to call make target/linux/compile, this step actually
 compiles the modules/.ko's. package/kernel/compile only packages them.



 Jonas

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

Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

2014-07-15 Thread Justin Vallon 
I don't think turning off the firewall is a sane default.  Your
arguments based on global addressability are false because IPv4 can be
globally addressable, if you want.  You can get static ip addresses (or
a subnet), turn off NAT, and turn off the firewall - every internal
network device will be on the public internet.

You say:  A general principle is that a service should not be bound on
a globally reachable address if it is not meant to be globally
accessible.  If my desktop is given an IPv6 address, are all of my
services now globally addressable?  If yes, I have opened up all local
services (oops).  If no, do I need a locally addressable and globally
addressable IPv6 space for each device  service, so that I can choose
which services I consider internal (my printer, my smb share) vs
external (my web server)?  That is pushing the security problem to the
terminal devices.

 I do not understand what the principle of least privilege has to do
here. “Forbidden by default” is not about privileges.

Privilege here is the right to do something; with respect to networking:
open a connection to any host, open a connection to a specific host,
allow incoming connections from any host.  Principle of least privilege
means that you only allow what is required - default is to restrict, not
allow.  Privileges are granted where necessary, instead of taken away
when abused.  Here, incoming connections represent a security risk
(hackers), and mitigation is that it becomes a privilege (to be
earned).  By default, incoming connections are not allowed, and uPNP
(etc) is used to request (and grant) that privilege.

-Justin


On 7/15/14, 1:43 PM, Benjamin Cama wrote:
 Le mardi 15 juillet 2014 à 11:45 -0400, Aaron Z a écrit :
 - Original Message -
 On Monday, July 14, 2014 5:36:09 PM Benjamin Cama ben...@dolka.fr wrote:
 Hi everyone,

 Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :
 I'd rather have Don't bother the user: things should generally
 just
 work, without having to configure anything (in this case, port
 forwarding).  But there is an obvious tradeoff with security.
 I agree with Baptiste here. There is no equivalent in IPv4 of “global
 reachability” by default with the NATs we have today, so we can't
 have
 the same defaults. Global reachability is how IP in general was meant
 to
 be; please, do not make it broken again.
 As I understand it, this is NOT adding NAT, but (by default) blocking
 unsolicited incoming connections from the outside world to devices on
 the internal network (which dont necessarily need to be accessible
 from the outside world).
 This thread is about choosing a sane default. Blocking by default means
 you can't have VoIP or P2P working out of the box. This was tricky with
 IPv4+NAT as it involves some trickery and software support (see UPnP and
 the like), but IPv6 offers the possibility to have it work without any
 supplemental development effort!

 When you say that devices don't “necessarily” need to be accessible, you
 already made a choice that is impossible to change back for 99.99% of
 people (which don't know how to tune a firewall).

 That is the whole point in using a firewall is it not? To keep people
 out of where they shouldn't be.
 Well, you can configure your “firewall” as it pleases you to block
 whatever you want, but the one in OpenWRT is quite “open” by default, as
 much as permit IPv4 (which is, only outbound connections are allowed;
 inbound connections are not possible “by design” by default because of
 NAT).

 Opening up the IPv6 firewall by default would be unexpected and I
 don't
 really like the approach for that matter and honestly I don't
 trust
 client devices that much.
 At least opening UDP ports  1024 seems pretty reasonable, and
 covers most
 use-cases regarding VoIP and video.  But it does indeed depart from
 the
 IPv4 case (not sure if it is such a bad idea though).
 This looks like a good compromise to me. Knowledgeable users can
 disable
 the firewall for needed hosts, while for others this “just work”. PCP
 may be coming one day, but it's still not there yet, so we need not
 to
 break the default configuration while waiting for it.
 Opening access from the outside to the inside as a default rule goes
 against the principle of least privilege on which firewall rules are
 generally predicated.
 I do not understand what the principle of least privilege has to do
 here. “Forbidden by default” is not about privileges.

 As I understand it, if a device on the inside of the network initiates
 the connection to a device on the outside (say from a VOIP phone to a
 VOIP server), return connections from the server are allowed.
 Yes, by looking at it from a very client-inside and server-outside (and
 TCP and state-tracking) view. That is a lot of presuppositions. This
 way, you can call a “server”, but nobody can call you.

 What gets blocked are unsolicited connections from the outside which
 are generally unneeded (and can be a security

Re: [OpenWrt-Devel] Sysupgrade to Barrier Breaker on au1000 (MTX-1)

2014-07-15 Thread Hauke Mehrtens 
On 07/15/2014 07:06 PM, Bruno Randolf wrote:
 Another problem I noted when upgrading from AA to BB on MTX-1:
 
 # sysupgrade -n /tmp/openwrt-au1000-au1500-jffs2-128k-sysupgrade.bin
 tar: openwrt-au1000-au1500-jffs2-128k.fs: not found in archive
 Invalid image contents
 Image check 'platform_check_image' failed.
 
 I needed to change in /lib/upgrade/platform.sh:
 ROOTFS_IMG=openwrt-au1000-au1500-root.fs
 
 In AA the ROOTFS image was called differently, the name in BB makes more
 sense, but how could we provide a good upgrade path from AA to BB?
 
 bruno

Thank you for the test, I changed the default kernel version to 3.10.44

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

[OpenWrt-Devel] About oldpackages/perl-*

2014-07-15 Thread Marcel Denia 

Hey everyone,

bugtracker seems to have some issues, so I'm posting here.
Some users reported[1][2] errors about all perl-* packages in oldpackages.
Perl was recently moved to the new GitHub repository. All remaining perl
modules expect the main perl directory to be present in their parent
directory, so that's what causes these error messages.
I guess they should be removed from oldpackages until updated ones are
ready(did anyone use them by the way?). They're broken beyond that error
message anyhow, so it's not that big of a loss.

[1] https://dev.openwrt.org/ticket/17116
[2] https://dev.openwrt.org/ticket/17133
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel