Re: [OpenWrt-Devel] b53: leaking packets for a second during initialization?

2014-01-30 Thread Rafał Miłecki
2014-01-30 Jonas Gorski :
> On Thu, Jan 30, 2014 at 1:59 PM, Rafał Miłecki  wrote:
>> * CONCLUSION *
>>
>> b53_switch_reset_gpio resets switch into a vulnerable state, where
>> machine behind the WAN can "access" LAN machines.
>> We need to put switch in some safe state before we call 
>> b53_switch_reset_gpio.
>> Example of configuring ports into a safe state is b53_enable_ports.
>>
>> Any idea what exactly we should do before calling b53_switch_reset_gpio?
>
> Can you see what happens if you clear SM_SW_FWD_EN before calling
> reset_gpio? Especially if it is set after reset? I would expect it to
> be reset to default state, and if SM_SW_FWD_EN set is the default
> state then we have a board problem we need to work around. If not then
> we can just disable forwarding before reset and re-enable it
> afterwards.

Unfortunately you're right :(

[ 3.58] b53_common: [b53_switch_reset:488] B53_SWITCH_MODE: 0x06
[ 3.59] b53_common: [b53_switch_reset:491] Unsetting SM_SW_FWD_EN (0x02)
[ 3.59] b53_common: [b53_switch_reset:494] B53_SWITCH_MODE: 0x04
[ 3.67] b53_common: [b53_switch_reset_gpio:480] GPIO reset done
[ 3.68] b53_common: [b53_switch_reset:500] B53_SWITCH_MODE: 0x06

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


Re: [OpenWrt-Devel] [PATCH 4/5] mvebu: update kernel config

2014-01-30 Thread Seif Mazareeb
Sure thing - will resubmit later today.

Seif

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf
> Of Jonas Gorski
> Sent: Thursday, January 30, 2014 3:39 AM
> To: OpenWrt Development List
> Cc: l...@openwrt.org; Adam Graham
> Subject: Re: [OpenWrt-Devel] [PATCH 4/5] mvebu: update kernel config
> 
> On Thu, Jan 30, 2014 at 9:27 AM, Seif Mazareeb 
> wrote:
> > The config-3.10 doesn't specify the configuration of the backported PCI
> > features, and the Marvell EBU Device Bus Controller, this will prevent
> > a clean compile. This patch enables these features to archive a clean
> compile
> > without having to specify the state of these configuration after starting to
> > compile.
> 
> This patch should be merged into patches 1-3 where the kernel config
> symbols get introduced/available, else applying only a subset of these
> patches will break the build (which can be annoying when bisecting).
> 
> 
> Regards
> Jonas
> ___
> 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] ubox, logd, log_size

2014-01-30 Thread Hannu Nyman

What where the problems (i'm curious)?


Regarding the problems, read discussion at bug 14838 (and earlier discussion 
also at 14227)

https://dev.openwrt.org/ticket/14838

There is no actual problem in the logging itself, but the problem is 
apparently a 64 kB ubus message maximum size set in ubusmsg.h.

http://nbd.name/gitweb.cgi?p=luci2/ubus.git;a=blob;f=ubusmsg.h;h=c9b92e7132edb039618a21921bc695396a722b0e;hb=4e82a1fabb87b5e3c948a792e16b0fac3702721b#l22

Logread sends a "log read request" via ubus to logd. Logd fills a message 
buffer with the required lines and returns it via ubus to logread, which then 
displays it for the user.


As logd adds quite a lot cleartext headers to each log line item in the 
blobmsg returned via ubus to logread, the 64 kB limit can be easily exceeded. 
With 48 kB log size (binary contents), the blob being returned can easily be 
over 90 kB.


I think it is a waste of resources to double the log size with a long 
cleartext header for each log line when there is a size constraint for the 
total message size (and while maintaining most of the log content still in 
binary format at this point).


In my own build I have increased the logsize to 30 kB (defined in syslog.c in 
ubox) , as then with the added cleartext headers the "log message" should 
still stay under 64 kB.


> Maybe logread should have an option to dump current buffer in the -F file?
During my debugging I used that approach to find out where the failure 
actually happened. Logd is nicely able to write to a file, but currently the 
log parsing routine is in logread, so logd itself is has only the binary 
contents of the log.

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


[OpenWrt-Devel] [PATCH] upgrade pyload to 0.4.9 and add LIBCURL_COOKIES as a dependency

2014-01-30 Thread Oliver Ertl
Signed-off-by: Oliver Ertl 
---
 net/pyload/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/pyload/Makefile b/net/pyload/Makefile
index 4a5d9e4..d6f237c 100644
--- a/net/pyload/Makefile
+++ b/net/pyload/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2011 OpenWrt.org
+# Copyright (C) 2011-2014 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=pyload
-PKG_VERSION:=0.4.8
+PKG_VERSION:=0.4.9
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-src-v$(PKG_VERSION).zip
 PKG_SOURCE_URL:=http://download.pyload.org/
-PKG_MD5SUM:=5bcf8411ef9e48ef6e9ade55bc697900
+PKG_MD5SUM:=28876150af22999b6f539c8579d3b415
 
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)/
 
@@ -26,7 +26,7 @@ define Package/pyload
   CATEGORY:=Network
   DEPENDS:=+python +pyopenssl +python-curl +python-crypto +python-django \
+python-expat +python-imaging-library +python-sqlite3 +js \
-   +tesseract +unrar
+   +tesseract +unrar +@LIBCURL_COOKIES
   TITLE:=A fast, lightweight and full featured download manager
   URL:=http://pyload.org
 endef
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] upgrade pyload to 0.4.9 and add LIBCURL_COOKIES as a dependency

2014-01-30 Thread Jonas Gorski
On Thu, Jan 30, 2014 at 6:33 PM, Oliver Ertl  wrote:
> Subject: [PATCH] upgrade pyload to 0.4.9 and add LIBCURL_COOKIES as a 
> dependency

This sounds like you are doing two more or less unrelated things at
once; a version bump and option select. Please split this into two
patches, and write something for the commit message, e.g. why
LIBCURL_COOKIES needs to be selected, and what happens without it.


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


[OpenWrt-Devel] [PATCH] upgrade pyload to 0.4.9 and add LIBCURL_COOKIES as a dependency

2014-01-30 Thread Oliver Ertl
Signed-off-by: Oliver Ertl 
---
 net/pyload/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/pyload/Makefile b/net/pyload/Makefile
index 4a5d9e4..d6f237c 100644
--- a/net/pyload/Makefile
+++ b/net/pyload/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2011 OpenWrt.org
+# Copyright (C) 2011-2014 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=pyload
-PKG_VERSION:=0.4.8
+PKG_VERSION:=0.4.9
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-src-v$(PKG_VERSION).zip
 PKG_SOURCE_URL:=http://download.pyload.org/
-PKG_MD5SUM:=5bcf8411ef9e48ef6e9ade55bc697900
+PKG_MD5SUM:=28876150af22999b6f539c8579d3b415
 
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)/
 
@@ -26,7 +26,7 @@ define Package/pyload
   CATEGORY:=Network
   DEPENDS:=+python +pyopenssl +python-curl +python-crypto +python-django \
+python-expat +python-imaging-library +python-sqlite3 +js \
-   +tesseract +unrar
+   +tesseract +unrar +@LIBCURL_COOKIES
   TITLE:=A fast, lightweight and full featured download manager
   URL:=http://pyload.org
 endef
-- 
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] AA: openssl: Support multi-threaded applications

2014-01-30 Thread Sujith Manoharan
From: Sujith Manoharan 

(This is a backport of r39048 from trunk).

Allow multi-threaded applications to work properly by
removing the "no-threads" flag that is enabled by default.

Signed-off-by: Sujith Manoharan 
---
 package/openssl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/openssl/Makefile b/package/openssl/Makefile
index a8b3257..fa08774 100644
--- a/package/openssl/Makefile
+++ b/package/openssl/Makefile
@@ -75,7 +75,7 @@ endef
 
 OPENSSL_NO_CIPHERS:= no-idea no-md2 no-mdc2 no-rc5 no-sha0 no-smime \
no-rmd160 no-aes192 no-ripemd no-camellia no-ans1 no-krb5
-OPENSSL_OPTIONS:= shared no-ec no-err no-hw no-threads zlib-dynamic no-sse2
+OPENSSL_OPTIONS:= shared no-ec no-err no-hw zlib-dynamic no-sse2
 
 ifdef CONFIG_OPENSSL_ENGINE_CRYPTO
   OPENSSL_OPTIONS += -DHAVE_CRYPTODEV
-- 
1.8.5.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] package maintainer request for mosquitto

2014-01-30 Thread Karl Palsson

Hi, 

I'd like to be the formal maintainer of the mosquitto package for openwrt.

I've asked in the past, and in 08f566d7c38cf49a18c3c4ee87bfd94dccdac1ff back in 
January 2013, I
was actually added as MAINTAINER in the package makefile, but I've never 
managed to actually get
maintainership directly.

luka on IRC suggested I try another another email :)


Current Pending patches for mosquitto:
http://patchwork.openwrt.org/patch/4667/
http://patchwork.openwrt.org/patch/4231/ (superseded by above)

I've been providing patches bumping along the versions for mosquitto
since bd511b4dcb6725857a5518e3eb7e8ff496b6a517 in August 2011

I maintain this externally already at 
https://github.com/remakeelectric/owrt_pub_feeds but it
would be nice to get it into OpenWrt a little faster at times.

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


[OpenWrt-Devel] [PATCH] Dragino2: add missing sysupgrade support.

2014-01-30 Thread Karl Palsson
From: Karl Palsson 

The original dragino2 board support was missing some changes from the
upstream svn repository (http://svn.dragino.com/dragino2) that supported
sysupgrade.

Signed-off-by: Karl Palsson 
---
 target/linux/ar71xx/base-files/lib/ar71xx.sh   | 3 +++
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 1 +
 2 files changed, 4 insertions(+)

diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index ce78367..3893747 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -279,6 +279,9 @@ ar71xx_board_detect() {
*"DIR-835 rev. A1")
name="dir-835-a1"
;;
+   *"Dragino v2")
+   name="dragino2"
+   ;;
*EAP7660D)
name="eap7660d"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 9d44f34..b2181af 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -149,6 +149,7 @@ platform_check_image() {
dir-615-e4 | \
dir-825-c1 | \
dir-835-a1 | \
+   dragino2 | \
ew-dorin | \
ew-dorin-router | \
hornet-ub-x2 | \
-- 
1.8.3.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] [packages] sane-backends: fix build on Archlinux

2014-01-30 Thread Dirk Neukirchen

configure.in tests CUPS and SYSTEMD with fixed host paths
leading to build failures on some systems (Arch)

change the tests to fix it

Signed-off-by: Dirk Neukirchen 
---
 .../patches/010-dont-add-host-include-path.patch   | 61 +-
 1 file changed, 60 insertions(+), 1 deletion(-)

diff --git a/utils/sane-backends/patches/010-dont-add-host-include-path.patch 
b/utils/sane-backends/patches/010-dont-add-host-include-path.patch
index cf9c8d8..1eb0b7e 100644
--- a/utils/sane-backends/patches/010-dont-add-host-include-path.patch
+++ b/utils/sane-backends/patches/010-dont-add-host-include-path.patch
@@ -1,6 +1,6 @@
 --- a/configure
 +++ b/configure
-@@ -5192,9 +5192,6 @@
+@@ -5192,9 +5192,6 @@ else
  fi
  
  
@@ -10,3 +10,62 @@
  if test "${ac_cv_c_compiler_gnu}" = "yes"; then
NORMAL_CFLAGS="\
-W \
+--- a/configure.in
 b/configure.in
+@@ -82,7 +82,7 @@ AM_CONDITIONAL(CROSS_COMPILING, test x$c
+ dnl ***
+ dnl set compiler/linker flags
+ dnl ***
+-INCLUDES="${INCLUDES} -I/usr/local/include"
++INCLUDES="${INCLUDES}"
+ AC_SUBST(INCLUDES)
+ SANE_SET_CFLAGS([$is_release])
+ SANE_SET_LDFLAGS
+@@ -332,30 +332,26 @@ if test -c /dev/urandom ; then
+ AC_DEFINE(HAVE_DEV_URANDOM, 1, [Is /dev/urandom available?])
+ fi
+ 
+-dnl added by PN 3/2/12 to detect cups
+-$as_echo "checking for cups"
+-if test -e /usr/include/cups/cups.h ; then
+-AC_DEFINE(HAVE_CUPS, 1, [Is /usr/include/cups/cups.h available?])
+-  with_cups="yes"
+-  LIBS="-lcups  $LIBS"
+-else
+-  $as_echo "cups.h not found, you may want to install a cups development 
package"
+-  $as_echo "in order to autodetect network scanners in kodakaio."
+-  with_cups="no"
++
++AC_PATH_PROG(CUPS_CONFIG, cups-config)
++CUPS_LIBS=`$CUPS_CONFIG --libs`
++
++AC_CHECK_HEADERS([cups/cups.h])
++PKG_CHECK_MODULES([HAVE_CUPS], [libcups], [with_cups=yes], [with_cups=no])
++if test "x${have_cups}" = "xyes"; then
++AC_DEFINE(HAVE_CUPS,[1],[Is cups/cups.h available?])
++LIBS="$LIBS $CUPS_LIBS"
+ fi
+ 
+-dnl added by llagendijk 12/7/2012 to detect systemd for saned
+-$as_echo_n "Checking for systemd..."
+-if test -e /usr/include/systemd/sd-daemon.h ; then
+-AC_DEFINE(HAVE_SYSTEMD, 1, [Is /usr/include/systemd/sd-daemon.h 
available?])
+-with_systemd="yes"
+-SYSTEMD_LIBS=" -lsystemd-daemon"
+-AC_SUBST(SYSTEMD_LIBS)
+-$as_echo "yes"
+-else
+-with_systemd="no"
+-$as_echo "no"
++
++AC_CHECK_HEADERS([systemd/sd-daemon.h])
++PKG_CHECK_MODULES([HAVE_SYSTEMD], [libsystemd-daemon], [with_systemd=yes], 
[with_systemd=no])
++if test "x${have_systemddaemon}" = "xyes"; then
++  AC_DEFINE(HAVE_SYSTEMD,[1],[Is systemd/sd-daemon.h available?])
++  SYSTEMD_LIBS=" -lsystemd-daemon"
+ fi
++AC_SUBST(SYSTEMD_LIBS)
++
+ 
+ dnl ***
+ dnl USB Support
-- 
1.8.5.3



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] [packages] upgrade baresip and libre/librem

2014-01-30 Thread Jiří Šlachta
Applied and a little bit enhanced in 1d2aadf8f8bbb0698d68ccecf9b2f9fd16bd4b1d 
in telephony!

Thank you!
Jiri

Dne 30. 1. 2014 11:49, Alfred E. Heggestad napsal(a):
> On 01/29/2014 09:21 PM, Jiří Šlachta wrote:
>> libre and librem patch applied in 10a7de705f16e942a577d7664c5c59b232b0f9b9!
>> Also, I've updated baresip to 0.4.10.
>>
> 
> Hi Jiri,
> 
> thank you very much. Can you also apply the patch below for baresip?
> some mandatory core modules also needs to be included in the package.
> 
> 
> 
> 
> From 87626dbedb0509985ff27f7f2e213b7a1703ad70 Mon Sep 17 00:00:00 2001
> From: "Alfred E. Heggestad" 
> Date: Thu, 30 Jan 2014 11:40:54 +0100
> Subject: [PATCH] baresip: added core modules
> 
> added some core modules that are required for basic
> operation:
> 
>   account.so   SIP account file parser
>   contact.so   Contact list (address book)
>   menu.so  Interactive menu
> 
> Signed-off-by: Alfred E. Heggestad 
> ---
>  net/baresip/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/baresip/Makefile b/net/baresip/Makefile
> index 042840a..167320a 100644
> --- a/net/baresip/Makefile
> +++ b/net/baresip/Makefile
> @@ -95,7 +95,10 @@ define Package/baresip/install
>  $(CP) $(PKG_INSTALL_DIR)/usr/bin/baresip $(1)/usr/bin/
>  $(INSTALL_DIR) $(1)/usr/lib/baresip/modules
>  $(CP) \
> +$(PKG_INSTALL_DIR)/usr/lib/baresip/modules/account.so \
> +$(PKG_INSTALL_DIR)/usr/lib/baresip/modules/contact.so \
>  $(PKG_INSTALL_DIR)/usr/lib/baresip/modules/ice.so \
> +$(PKG_INSTALL_DIR)/usr/lib/baresip/modules/menu.so \
>  $(PKG_INSTALL_DIR)/usr/lib/baresip/modules/stun.so \
>  $(PKG_INSTALL_DIR)/usr/lib/baresip/modules/turn.so \
>  $(1)/usr/lib/baresip/modules/.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] b53: leaking packets for a second during initialization?

2014-01-30 Thread Jonas Gorski
On Thu, Jan 30, 2014 at 1:59 PM, Rafał Miłecki  wrote:
> 2014-01-30 Florian Fainelli :
>> 2014-01-29 Rafał Miłecki :
>>> 2014-01-28 Jonas Gorski :
 On Tue, Jan 28, 2014 at 8:41 PM, Rafał Miłecki  wrote:
>>> On my:
 Found chip with id 0x5357, rev 0x02 and package 0x0A
>>> code
>>> if (!(mgmt & SM_SW_FWD_EN)) {
>>> ...
>>> }
>>> is never called, because that bit is already set:
 b53_common: B53_SWITCH_MODE: 0x06 (SM_SW_FWD_EN:0x02)
>>>
>>> So this won't help, because SM_SW_FWD_EN is already set after reset.
>>
>> SM_SW_FWD_EN can be overriden using hardware straps, which is probably
>> the reason why it is already set after reset for your case and why you
>> are seeing leakage. Ideally the bootloader would have cleared that bit
>> to make sure it puts the switch back into unconfigured managed mode
>> and avoid the leakage.
>>
>> If you have some way to access the MII registers in CFE, try to clear
>> that bit and see if the leakage still happens?
>
> No, (mine) CFE doesn't have tools like that.
>
> I've applied attached patch to see what actually makes switch allow
> transfer between LANs and WAN ports. I setup two machines:
> 1) Notebook connected to one of the LAN ports (static 192.168.1.2)
> 2) PC connected to the WAN port (static 192.168.1.3)
>
> Right after early OpenWrt booting, before b53 kicks in, machines were
> *not* able to talk. After modified b53 was started:
> [ 3.54] bgmac bcma0:1: Found PHY addr: 30 (NOREGS)
> [ 3.55] bgmac bcma0:1: Support for Roboswitch not implemented
> [ 3.56] libphy: bgmac mii bus: probed
> [ 3.57] b53_common: [b53_switch_reset:488] B53_SWITCH_MODE: 0x06
> [ 3.65] b53_common: [b53_switch_reset_gpio:480] GPIO reset done
> [ 3.65] b53_common: [b53_switch_reset:493] B53_SWITCH_MODE: 0x06
> [ 3.66] b53_common: [b53_switch_reset:496] ABORT
> [ 3.67] b53_common: found switch: BCM53125, rev 4
> [ 3.67] bgmac: Broadcom 47xx GBit MAC driver loaded
> [ 5.67] libphy: bgmac-0-0:1e - Link is Up - 1000/Full
> [ 11.80] NET: Registered protocol family 10
> [ 11.81] nf_conntrack version 0.5.0 (965 buckets, 3860 max)
> [ 11.83] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [ 11.86] ip_tables: (C) 2000-2006 Netfilter Core Team
> [ 11.92] xt_time: kernel timezone is -
> [ 11.93] PPP generic driver version 2.4.2
> [ 11.94] NET: Registered protocol family 24
> [ 15.65] b53_common: [b53_global_apply_config:803] ABORT
> machines were able to talk (ping each other).
>
> As you can see, my patch aborts all switch configuration leaving only
> call to the b53_switch_reset_gpio on the beginning of
> b53_switch_reset.
>
> So:
> 1) Before b53_switch_reset_gpio LAN ports and WAN port are separated
> 2) After b53_switch_reset_gpio LAN ports and WAN port are the same 
> network/VLAN
>
> After above test I started moving my:
>> /* Abort at this early point to see what happens after GPIO reset */
>> pr_info("[%s:%d] ABORT\n", __FUNCTION__, __LINE__);
>> return 0;
> to see what part of code will make LAN port and WAN port separated
> again. It is call to the b53_enable_ports.
>
> If I put my "return 0;" right after calling "b53_enable_ports"
> (everything in b53_switch_reset) - it's enough. After allowing this
> call to "b53_enable_ports" my machines were not able to talk each
> other anymore.
>
> * CONCLUSION *
>
> b53_switch_reset_gpio resets switch into a vulnerable state, where
> machine behind the WAN can "access" LAN machines.
> We need to put switch in some safe state before we call b53_switch_reset_gpio.
> Example of configuring ports into a safe state is b53_enable_ports.
>
> Any idea what exactly we should do before calling b53_switch_reset_gpio?

Can you see what happens if you clear SM_SW_FWD_EN before calling
reset_gpio? Especially if it is set after reset? I would expect it to
be reset to default state, and if SM_SW_FWD_EN set is the default
state then we have a board problem we need to work around. If not then
we can just disable forwarding before reset and re-enable it
afterwards.


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


Re: [OpenWrt-Devel] b53: leaking packets for a second during initialization?

2014-01-30 Thread Rafał Miłecki
2014-01-30 Florian Fainelli :
> 2014-01-29 Rafał Miłecki :
>> 2014-01-28 Jonas Gorski :
>>> On Tue, Jan 28, 2014 at 8:41 PM, Rafał Miłecki  wrote:
>> On my:
>>> Found chip with id 0x5357, rev 0x02 and package 0x0A
>> code
>> if (!(mgmt & SM_SW_FWD_EN)) {
>> ...
>> }
>> is never called, because that bit is already set:
>>> b53_common: B53_SWITCH_MODE: 0x06 (SM_SW_FWD_EN:0x02)
>>
>> So this won't help, because SM_SW_FWD_EN is already set after reset.
>
> SM_SW_FWD_EN can be overriden using hardware straps, which is probably
> the reason why it is already set after reset for your case and why you
> are seeing leakage. Ideally the bootloader would have cleared that bit
> to make sure it puts the switch back into unconfigured managed mode
> and avoid the leakage.
>
> If you have some way to access the MII registers in CFE, try to clear
> that bit and see if the leakage still happens?

No, (mine) CFE doesn't have tools like that.

I've applied attached patch to see what actually makes switch allow
transfer between LANs and WAN ports. I setup two machines:
1) Notebook connected to one of the LAN ports (static 192.168.1.2)
2) PC connected to the WAN port (static 192.168.1.3)

Right after early OpenWrt booting, before b53 kicks in, machines were
*not* able to talk. After modified b53 was started:
[ 3.54] bgmac bcma0:1: Found PHY addr: 30 (NOREGS)
[ 3.55] bgmac bcma0:1: Support for Roboswitch not implemented
[ 3.56] libphy: bgmac mii bus: probed
[ 3.57] b53_common: [b53_switch_reset:488] B53_SWITCH_MODE: 0x06
[ 3.65] b53_common: [b53_switch_reset_gpio:480] GPIO reset done
[ 3.65] b53_common: [b53_switch_reset:493] B53_SWITCH_MODE: 0x06
[ 3.66] b53_common: [b53_switch_reset:496] ABORT
[ 3.67] b53_common: found switch: BCM53125, rev 4
[ 3.67] bgmac: Broadcom 47xx GBit MAC driver loaded
[ 5.67] libphy: bgmac-0-0:1e - Link is Up - 1000/Full
[ 11.80] NET: Registered protocol family 10
[ 11.81] nf_conntrack version 0.5.0 (965 buckets, 3860 max)
[ 11.83] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 11.86] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 11.92] xt_time: kernel timezone is -
[ 11.93] PPP generic driver version 2.4.2
[ 11.94] NET: Registered protocol family 24
[ 15.65] b53_common: [b53_global_apply_config:803] ABORT
machines were able to talk (ping each other).

As you can see, my patch aborts all switch configuration leaving only
call to the b53_switch_reset_gpio on the beginning of
b53_switch_reset.

So:
1) Before b53_switch_reset_gpio LAN ports and WAN port are separated
2) After b53_switch_reset_gpio LAN ports and WAN port are the same network/VLAN

After above test I started moving my:
> /* Abort at this early point to see what happens after GPIO reset */
> pr_info("[%s:%d] ABORT\n", __FUNCTION__, __LINE__);
> return 0;
to see what part of code will make LAN port and WAN port separated
again. It is call to the b53_enable_ports.

If I put my "return 0;" right after calling "b53_enable_ports"
(everything in b53_switch_reset) - it's enough. After allowing this
call to "b53_enable_ports" my machines were not able to talk each
other anymore.

* CONCLUSION *

b53_switch_reset_gpio resets switch into a vulnerable state, where
machine behind the WAN can "access" LAN machines.
We need to put switch in some safe state before we call b53_switch_reset_gpio.
Example of configuring ports into a safe state is b53_enable_ports.

Any idea what exactly we should do before calling b53_switch_reset_gpio?

-- 
Rafał
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c 
b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
index f6a5418..6ce6660 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
@@ -476,14 +476,26 @@ static void b53_switch_reset_gpio(struct b53_device *dev)
mdelay(20);
 
dev->current_page = 0xff;
+
+   pr_info("[%s:%d] GPIO reset done\n", __FUNCTION__, __LINE__);
 }
 
 static int b53_switch_reset(struct b53_device *dev)
 {
u8 mgmt;
 
+   b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
+   pr_info("[%s:%d] B53_SWITCH_MODE: 0x%02X\n", __FUNCTION__, __LINE__, 
mgmt);
+
b53_switch_reset_gpio(dev);
 
+   b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
+   pr_info("[%s:%d] B53_SWITCH_MODE: 0x%02X\n", __FUNCTION__, __LINE__, 
mgmt);
+
+   /* Abort at this early point to see what happens after GPIO reset */
+   pr_info("[%s:%d] ABORT\n", __FUNCTION__, __LINE__);
+   return 0;
+
if (is539x(dev)) {
b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, 0x83);
b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, 0x00);
@@ -778,6 +790,8 @@ static int b53_global_reset_switch(struct switch_dev *dev)
memset(priv->vlans, 0, sizeof(priv->vlans) * dev->vlans);
memset(priv->ports, 0, sizeof(priv->ports) * dev->ports);
 
+ 

Re: [OpenWrt-Devel] [PATCH 4/5] mvebu: update kernel config

2014-01-30 Thread Jonas Gorski
On Thu, Jan 30, 2014 at 9:27 AM, Seif Mazareeb  wrote:
> The config-3.10 doesn't specify the configuration of the backported PCI
> features, and the Marvell EBU Device Bus Controller, this will prevent
> a clean compile. This patch enables these features to archive a clean compile
> without having to specify the state of these configuration after starting to
> compile.

This patch should be merged into patches 1-3 where the kernel config
symbols get introduced/available, else applying only a subset of these
patches will break the build (which can be annoying when bisecting).


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


Re: [OpenWrt-Devel] [PATCH] [packages] upgrade baresip and libre/librem

2014-01-30 Thread Alfred E. Heggestad

On 01/29/2014 09:21 PM, Jiří Šlachta wrote:

libre and librem patch applied in 10a7de705f16e942a577d7664c5c59b232b0f9b9!
Also, I've updated baresip to 0.4.10.



Hi Jiri,

thank you very much. Can you also apply the patch below for baresip?
some mandatory core modules also needs to be included in the package.




From 87626dbedb0509985ff27f7f2e213b7a1703ad70 Mon Sep 17 00:00:00 2001
From: "Alfred E. Heggestad" 
Date: Thu, 30 Jan 2014 11:40:54 +0100
Subject: [PATCH] baresip: added core modules

added some core modules that are required for basic
operation:

  account.so   SIP account file parser
  contact.so   Contact list (address book)
  menu.so  Interactive menu

Signed-off-by: Alfred E. Heggestad 
---
 net/baresip/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/baresip/Makefile b/net/baresip/Makefile
index 042840a..167320a 100644
--- a/net/baresip/Makefile
+++ b/net/baresip/Makefile
@@ -95,7 +95,10 @@ define Package/baresip/install
$(CP) $(PKG_INSTALL_DIR)/usr/bin/baresip $(1)/usr/bin/
$(INSTALL_DIR) $(1)/usr/lib/baresip/modules
$(CP) \
+   $(PKG_INSTALL_DIR)/usr/lib/baresip/modules/account.so \
+   $(PKG_INSTALL_DIR)/usr/lib/baresip/modules/contact.so \
$(PKG_INSTALL_DIR)/usr/lib/baresip/modules/ice.so \
+   $(PKG_INSTALL_DIR)/usr/lib/baresip/modules/menu.so \
$(PKG_INSTALL_DIR)/usr/lib/baresip/modules/stun.so \
$(PKG_INSTALL_DIR)/usr/lib/baresip/modules/turn.so \
$(1)/usr/lib/baresip/modules/.
--
1.8.5.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] hostapd: fix basic_rate list format

2014-01-30 Thread Daniel
hostapd expects basic_rates list to be space separated and in
100kbit/s units.
---
 package/network/services/hostapd/files/netifd.sh | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/package/network/services/hostapd/files/netifd.sh
b/package/network/services/hostapd/files/netifd.sh
index c8518b4..2e8e045 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -1,9 +1,7 @@
 hostapd_add_rate() {
local var="$1"
-   local val="$(($2 / 1000))"
-   local sub="$((($2 / 100) % 10))"
-   append $var "$val" ","
-   [ $sub -gt 0 ] && append $var "."
+   local val="$(($2 / 100))"
+   append $var "$val" " "
 }
  hostapd_append_wep_key() {
-- 
1.8.5.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 5/5] mvebu: add support for the Armada XP GP board (DB-MV784MP-GP)

2014-01-30 Thread Seif Mazareeb
This Armada XP GP board from Marvell comes with:

* 2GB DDR3 DIMM
* 1GB NAND flash (8-bit interface)
* 16MB NOR flash (16-bot interrface)
* 16MB SPI flash
* SDIO module
* 3 PCIe
* 1 SATA link
* 2 USB EHCI
* 1 internal SSD
* 4 Ethernet Gigabit
* 1 RS232 port over USB

Signed-off-by: Seif Mazareeb 
---
 target/linux/mvebu/base-files/lib/mvebu.sh |3 +++
 target/linux/mvebu/image/Makefile  |2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/linux/mvebu/base-files/lib/mvebu.sh 
b/target/linux/mvebu/base-files/lib/mvebu.sh
index 727b6b5..5bc35ef 100644
--- a/target/linux/mvebu/base-files/lib/mvebu.sh
+++ b/target/linux/mvebu/base-files/lib/mvebu.sh
@@ -28,6 +28,9 @@ mvebu_board_detect() {
*"PlatHome OpenBlocks AX3-4 board")
name="openblocks-ax3-4"
;;
+   *"Marvell Armada XP GP Board")
+   name="armada-xp-gp"
+   ;;
esac
 
[ -z "$name" ] && name="unknown"
diff --git a/target/linux/mvebu/image/Makefile 
b/target/linux/mvebu/image/Makefile
index 1e4a791..e89530a 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/image.mk
 
 TARGET_DTBS := armada-xp-db armada-370-db armada-xp-openblocks-ax3-4 
armada-370-mirabox \
-   armada-370-rd
+   armada-370-rd armada-xp-gp
 
 LOADADDR:=0x8000
 
-- 
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 4/5] mvebu: update kernel config

2014-01-30 Thread Seif Mazareeb
The config-3.10 doesn't specify the configuration of the backported PCI
features, and the Marvell EBU Device Bus Controller, this will prevent
a clean compile. This patch enables these features to archive a clean compile
without having to specify the state of these configuration after starting to
compile.

Signed-off-by: Seif Mazareeb 
---
 target/linux/mvebu/config-3.10 |   17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/target/linux/mvebu/config-3.10 b/target/linux/mvebu/config-3.10
index 0fba064..a8cc779 100644
--- a/target/linux/mvebu/config-3.10
+++ b/target/linux/mvebu/config-3.10
@@ -12,7 +12,6 @@ CONFIG_ARCH_MULTI_V7=y
 CONFIG_ARCH_MVEBU=y
 # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
 CONFIG_ARCH_NR_GPIO=0
-# CONFIG_ARCH_OMAP2PLUS is not set
 CONFIG_ARCH_REQUIRE_GPIOLIB=y
 # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
 # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
@@ -44,6 +43,7 @@ CONFIG_CACHE_L2X0=y
 CONFIG_CACHE_PL310=y
 CONFIG_CLKDEV_LOOKUP=y
 CONFIG_CLKSRC_MMIO=y
+CONFIG_CLKSRC_OF=y
 CONFIG_CLONE_BACKWARDS=y
 CONFIG_COMMON_CLK=y
 CONFIG_CPU_32v6K=y
@@ -69,6 +69,7 @@ CONFIG_DEBUG_INFO=y
 CONFIG_DEBUG_LL=y
 CONFIG_DEBUG_LL_INCLUDE="debug/mvebu.S"
 CONFIG_DEBUG_MVEBU_UART=y
+# CONFIG_DEBUG_MVEBU_UART_ALTERNATE is not set
 # CONFIG_DEBUG_PINCTRL is not set
 CONFIG_DEBUG_UNCOMPRESS=y
 CONFIG_DEBUG_USER=y
@@ -124,6 +125,7 @@ CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
 CONFIG_HAVE_FUNCTION_TRACER=y
 CONFIG_HAVE_GENERIC_DMA_COHERENT=y
 CONFIG_HAVE_GENERIC_HARDIRQS=y
+CONFIG_HAVE_IDE=y
 CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
 CONFIG_HAVE_KERNEL_GZIP=y
 CONFIG_HAVE_KERNEL_LZMA=y
@@ -161,6 +163,7 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_MARVELL_PHY=y
 CONFIG_MDIO_BOARDINFO=y
 CONFIG_MEMORY=y
+CONFIG_MIGHT_HAVE_PCI=y
 CONFIG_MODULES_USE_ELF_REL=y
 CONFIG_MSDOS_FS=y
 CONFIG_MTD_CFI_STAA=y
@@ -170,15 +173,16 @@ CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_MULTI_IRQ_HANDLER=y
 CONFIG_MUTEX_SPIN_ON_OWNER=y
 CONFIG_MVEBU_CLK_CORE=y
+CONFIG_MVEBU_CLK_COREDIV=y
 CONFIG_MVEBU_CLK_CPU=y
 CONFIG_MVEBU_CLK_GATING=y
+CONFIG_MVEBU_DEVBUS=y
 CONFIG_MVEBU_MBUS=y
 CONFIG_MVMDIO=y
 CONFIG_MVNETA=y
 CONFIG_MV_XOR=y
 CONFIG_NEED_DMA_MAP_STATE=y
 # CONFIG_NEON is not set
-# CONFIG_NET_DMA is not set
 CONFIG_NLS=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_850=y
@@ -196,13 +200,17 @@ CONFIG_OF_IRQ=y
 CONFIG_OF_MDIO=y
 CONFIG_OF_MTD=y
 CONFIG_OF_NET=y
+CONFIG_OF_PCI=y
+CONFIG_OF_PCI_IRQ=y
 CONFIG_OLD_SIGACTION=y
 CONFIG_OLD_SIGSUSPEND3=y
 CONFIG_OUTER_CACHE=y
 CONFIG_OUTER_CACHE_SYNC=y
 CONFIG_PAGEFLAGS_EXTENDED=y
 CONFIG_PAGE_OFFSET=0xC000
-# CONFIG_PCI_SYSCALL is not set
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_MVEBU=y
 CONFIG_PERF_USE_VMALLOC=y
 CONFIG_PHYLIB=y
 CONFIG_PINCONF=y
@@ -246,8 +254,7 @@ CONFIG_UDF_FS=m
 CONFIG_UID16=y
 CONFIG_UIDGID_CONVERTED=y
 CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
-# CONFIG_USB_ARCH_HAS_OHCI is not set
-# CONFIG_USB_ARCH_HAS_XHCI is not set
+CONFIG_USB_ARCH_HAS_XHCI=y
 CONFIG_USB_SUPPORT=y
 CONFIG_USE_GENERIC_SMP_HELPERS=y
 CONFIG_USE_OF=y
-- 
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel