Re: [OpenWrt-Devel] [PATCH] ramips: mt7620: fix failsafe switch config

2016-03-01 Thread John Crispin 


On 01/03/2016 17:15, Joseph C. Lehner wrote:
> This patch applies to both Chaos Calmer and trunk.


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

Re: [OpenWrt-Devel] current state of kirkwood target in trunk?

2016-03-01 Thread Alexander Couzens 
On Mon, 29 Feb 2016 22:57:46 +0100
Martin Mueller  wrote:

> So my question is, what is the supposed way to get openwrt on the
> goflex? In case the ubifs is correct, in which direction do I need to
> search to get it running.

Hi,

I got similiar problems and migrated the dockstar to ubi(kernel,squashfs,ubifs).
It boots on my dockstar with a fresh compiled and flashed first stage 
bootloader.

Is there a better solution than installing the factory image through an 
initramfs?


tftpboot 0x8000 openwrt-kirkwood-dockstar-initramfs-kernel.bin
bootz 0x8000

# if ubidriver already found an ubi, detach first
ubidetach -p /dev/mtd3
# format it
ubiformat -f /tmp/openwrt-kirkwood-dockstar-squashfs-factory.bin /dev/mtd3

The goflex is coming next.
Sending the patch series for the dockstar later.

Best,
lynxis
-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpvBRYr7VFca.pgp
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] ramips: mt7620: fix failsafe switch config

2016-03-01 Thread Joseph C. Lehner 
I see that the patch has been merged in trunk, however the same
issue exists in Chaos Calmer (and this patch applies to the CC
branch as well).

Regards,
Joseph


On 2016-02-17 17:58, Joseph C. Lehner wrote:
> As indicated in the bug tracker[1], failsafe mode is broken on at least some
> devices using the mt7620 switch (and possibly mt7621). The thread explicitly
> mentions the Xiaomi MiWifi, and the Nexx WT3020, and an unspecified device
> using the mt7621 switch; the issue also applies to the Netgear EX2700.
> 
> The problem is that failsafe mode uses eth0, but enable_vlan is always set to 
> 1
> by the switch driver. Connecting to and/or pinging the device fails. This 
> patch 
> fixes the failsafe preinit config, by making sure that vlan support is 
> disabled. 
> It currently only fixes the switch config on mt7620, but might apply to the 
> mt7621 as well, so the patch has been designed with this in mind.
> 
> A similar (line wrapped) patch was submitted in December by Simon Peter, but 
> never
> accepted and/or discussed.
> 
> This patch applies to both Chaos Calmer and trunk.
> 
> [1] https://dev.openwrt.org/ticket/18768
> 
> Signed-off-by: Joseph C. Lehner 
> 
> ---
> 
> diff --git 
> a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips 
> b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
> index 3dce1b6..6948851 100644
> --- a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
> +++ b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
> @@ -7,8 +7,22 @@
>  
>  ramips_set_preinit_iface() {
>   RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350|MT7628|MT7688)"`
> + MT762X=`cat /proc/cpuinfo | egrep "MT7620"`
> +
>   if [ -n "${RT3X5X}" ]; then
>   swconfig dev rt305x set reset 1
> + elif [ -n "${MT762X}" ]; then
> + # The mt7530 switch driver enables VLAN by default, but
> + # failsafe uses eth0, making the device unreachable:
> + # https://dev.openwrt.org/ticket/18768
> + case "${MT762X}" in
> + *MT7620*)
> + mt762x_switchdev=mt7620
> + ;;
> + esac
> + swconfig dev $mt762x_switchdev set reset 1
> + swconfig dev $mt762x_switchdev set enable_vlan 0
> + swconfig dev $mt762x_switchdev set apply 1
>   fi
>  
>   if echo $RT3X5X | egrep -q "(RT5350|MT7628|MT7688)"; then
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lua: host: install lnum_config.h

2016-03-01 Thread Matthias Schiffer 
One of the host patches introduces the new header file lnum_config.h
included by luaconf.h, but doesn't install it.

Install it to allow building C modules for the host Lua.

Signed-off-by: Matthias Schiffer 
---
 .../lua/patches-host/010-lua-5.1.3-lnum-full-260308.patch | 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/package/utils/lua/patches-host/010-lua-5.1.3-lnum-full-260308.patch 
b/package/utils/lua/patches-host/010-lua-5.1.3-lnum-full-260308.patch
index 74b8c6f..2a04ce0 100644
--- a/package/utils/lua/patches-host/010-lua-5.1.3-lnum-full-260308.patch
+++ b/package/utils/lua/patches-host/010-lua-5.1.3-lnum-full-260308.patch
@@ -1,3 +1,14 @@
+--- a/Makefile
 b/Makefile
+@@ -42,7 +42,7 @@
+ 
+ # What to install.
+ TO_BIN= lua luac
+-TO_INC= lua.h luaconf.h lualib.h lauxlib.h ../etc/lua.hpp
++TO_INC= lua.h luaconf.h lualib.h lauxlib.h lnum_config.h ../etc/lua.hpp
+ TO_LIB= liblua.a
+ TO_MAN= lua.1 luac.1
+ 
 --- a/src/Makefile
 +++ b/src/Makefile
 @@ -25,7 +25,7 @@ PLATS= aix ansi bsd freebsd generic linu
-- 
2.7.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: EX2700: remove unused kernel modules

2016-03-01 Thread Joseph C. Lehner 
Remove the kmod-mt76 package from the EX2700 profile to free up
around 100 KiB of space on the root filesystem.

This patch applies to both trunk and Chaos Calmer.

Signed-off-by: Joseph C. Lehner 

---

Changes in v2:
* Don't remove kmod-rt2800-pci


diff --git a/target/linux/ramips/mt7620/profiles/netgear.mk
b/target/linux/ramips/mt7620/profiles/netgear.mk
index d1b073a..9631537 100644
--- a/target/linux/ramips/mt7620/profiles/netgear.mk
+++ b/target/linux/ramips/mt7620/profiles/netgear.mk
@@ -7,7 +7,8 @@

 define Profile/EX2700
NAME:=Netgear EX2700
-   PACKAGES:=-kmod-usb-core -kmod-usb2 -kmod-usb-ohci -kmod-ledtrig-usbdev
+   PACKAGES:=-kmod-usb-core -kmod-usb2 -kmod-usb-ohci -kmod-ledtrig-usbdev 
\
+   -kmod-mt76
 endef

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

[OpenWrt-Devel] [CC 15.05] openssl: Security update (9 CVEs)

2016-03-01 Thread jow 
The openssl package has been rebuilt and was uploaded to the Chaos
Calmer 15.05 repository due to multiple security issues.


VERSION

1.0.2f-1 => 1.0.2g-1


CHANGELOG

[Tue, 1 Mar 2016 15:18:24 + f4368a7]

CVE-2016-0704

s2_srvr.c overwrite the wrong bytes in the master-key when applying
Bleichenbacher protection for export cipher suites. This provides a
Bleichenbacher oracle, and could potentially allow more efficient
variants of the DROWN attack.

CVE-2016-0703

s2_srvr.c did not enforce that clear-key-length is 0 for non-export
ciphers. If clear-key bytes are present for these ciphers, they
*displace* encrypted-key bytes. This leads to an efficient
divide-and-conquer key recovery attack: if an eavesdropper has
intercepted an SSLv2 handshake, they can use the server as an oracle to
determine the SSLv2 master-key, using only 16 connections to the server
and negligible computation. More importantly, this leads to a more
efficient version of DROWN that is effective against non-export
ciphersuites, and requires no significant computation.

CVE-2016-0702

A side-channel attack was found which makes use of cache-bank conflicts
on the Intel Sandy-Bridge microarchitecture which could lead to the
recovery of RSA keys. The ability to exploit this issue is limited as it
relies on an attacker who has control of code in a thread running on the
same hyper- threaded core as the victim thread which is performing
decryptions.

CVE-2016-0799

The internal |fmtstr| function used in processing a "%s" format string
in the BIO_*printf functions could overflow while calculating the length
of a string and cause an OOB read when printing very long strings.
Additionally the internal |doapr_outch| function can attempt to write to
an OOB memory location (at an offset from the NULL pointer) in the event
of a memory allocation failure. In 1.0.2 and below this could be caused
where the size of a buffer to be allocated is greater than INT_MAX. E.g.
this could be in processing a very long "%s" format string. Memory leaks
can also occur. The first issue may mask the second issue dependent on
compiler behaviour. These problems could enable attacks where large
amounts of untrusted data is passed to the BIO_*printf functions. If
applications use these functions in this way then they could be
vulnerable. OpenSSL itself uses these functions when printing out
human-readable dumps of ASN.1 data. Therefore applications that print
this data could be vulnerable if the data is from untrusted sources.
OpenSSL command line applications could also be vulnerable where they
print out ASN.1 data, or if untrusted data is passed as command line
arguments. Libssl is not considered directly vulnerable. Additionally
certificates etc received via remote connections via libssl are also
unlikely to be able to trigger these issues because of message size
limits enforced within libssl.

CVE-2016-0797

In the BN_hex2bn function the number of hex digits is calculated using
an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
For large values of |i| this can result in |bn_expand| not allocating
any memory because |i * 4| is negative. This can leave the internal
BIGNUM data field as NULL leading to a subsequent NULL ptr deref. For
very large values of |i|, the calculation |i * 4| could be a positive
value smaller than |i|. In this case memory is allocated to the internal
BIGNUM data field, but it is insufficiently sized leading to heap
corruption. A similar issue exists in BN_dec2bn. This could have
security consequences if BN_hex2bn/BN_dec2bn is ever called by user
applications with very large untrusted hex/dec data. This is anticipated
to be a rare occurrence. All OpenSSL internal usage of these functions
use data that is not expected to be untrusted, e.g. config file data or
application command line arguments. If user developed applications
generate config file data based on untrusted data then it is possible
that this could also lead to security consequences. This is also
anticipated to be rare.

CVE-2016-0798

The SRP user database lookup method SRP_VBASE_get_by_user had confusing
memory management semantics; the returned pointer was sometimes newly
allocated, and sometimes owned by the callee. The calling code has no
way of distinguishing these two cases. Specifically, SRP servers that
configure a secret seed to hide valid login information are vulnerable
to a memory leak: an attacker connecting with an invalid username can
cause a memory leak of around 300 bytes per connection. Servers that do
not configure SRP, or configure SRP but do not configure a seed are not
vulnerable. In Apache, the seed directive is known as
SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in
SRP_VBASE_get_by_user is now disabled even if the user has configured a
seed. Applications are advised to migrate to SRP_VBASE_get1_by_user.
However, note that OpenSSL makes no strong guarantees about the
indistinguishability of valid and invalid

[OpenWrt-Devel] NetJSON status at the beginning of 2016

2016-03-01 Thread Nemesis 
Hi everyone,

last year I announced [1] an initiative to create a few common JSON data
structures to improve interoperability,
you can find that announcemente at:

More than 1 year has passed since that announcement and today we have an
RFC [2] and a few implementations [3].
The RFC has not been sent to the IETF yet but it is our intention to do
so in the coming months.

The "DeviceConfiguration" object [4] is particularly relevant for
OpenWRT, because it has been inspired a lot by
the ubus output.

The two implementations that deal with configurations are netjsonconfig
[5] and django-netjsonconfig [6].

Since the RFC is still draft version 0, there's still wide room for
improvement before sending it to the IETF
and thatis why I'm sending this email: I invite anyone interested in the
subject to participate in this process now rather than later.
Please forward this email if you think other groups might be interested
in participating in the discussion.

Federico Capoano

[1] announcement:
https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030422.html
[2] NetJSON RFC: http://netjson.org/rfc.html
[3] NetJSON implementations:
https://github.com/interop-dev/netjson#implementations
[4] DeviceConfiguration object: http://netjson.org/rfc.html#rfc.section.5
[5] netjsonconfig: http://netjsonconfig.openwisp.org/
[6] django-netjsonconfig: https://github.com/openwisp/django-netjsonconfig


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

[OpenWrt-Devel] [PATCH] mtd: fix reading of image magic bytes in smaller chunks

2016-03-01 Thread Sven Eckelmann 
From: Sven Eckelmann 

The image_check currently fails when it cannot read all magic bytes in a
single chunk. But this can happen when the data are read from a pipe. This
currently breaks the openmesh.sh upgrade script with musl because it uses
dd with a blocksize of 1 to copy the image file to the mtd process.

The read can simply be repeated until enough bytes are read for the magic
byte check. It only stops when either an error was returned or 0 bytes were
read.

Signed-off-by: Sven Eckelmann 
---
 package/system/mtd/src/mtd.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c
index eda001e..dae0514 100644
--- a/package/system/mtd/src/mtd.c
+++ b/package/system/mtd/src/mtd.c
@@ -179,14 +179,21 @@ image_check(int imagefd, const char *mtd)
 {
uint32_t magic;
int ret = 1;
+   int bufread;
+
+   while (buflen < sizeof(magic)) {
+   bufread = read(imagefd, buf + buflen, sizeof(magic) - buflen);
+   if (bufread < 1)
+   break;
+
+   buflen += bufread;
+   }
 
if (buflen < sizeof(magic)) {
-   buflen += read(imagefd, buf + buflen, sizeof(magic) - buflen);
-   if (buflen < sizeof(magic)) {
-   fprintf(stdout, "Could not get image magic\n");
-   return 0;
-   }
+   fprintf(stdout, "Could not get image magic\n");
+   return 0;
}
+
magic = ((uint32_t *)buf)[0];
 
if (be32_to_cpu(magic) == TRX_MAGIC)
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] om-watchdog: Move each board name to its own line

2016-03-01 Thread Sven Eckelmann 
From: Sven Eckelmann 

Signed-off-by: Sven Eckelmann 
---
 package/kernel/om-watchdog/files/om-watchdog.init | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/package/kernel/om-watchdog/files/om-watchdog.init 
b/package/kernel/om-watchdog/files/om-watchdog.init
index 47105f2..d68fb15 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -16,19 +16,25 @@ get_gpio() {
local board=$(ar71xx_board_name)
 
case "$board" in
-   "om2p"|"om2p-hs"|"om2p-hsv2")
+   "om2p" | \
+   "om2p-hs" | \
+   "om2p-hsv2")
return 12
;;
-   "om2pv2"|"om2p-lc")
+   "om2pv2" | \
+   "om2p-lc")
return 26
;;
-   "om5p"|"om5p-an")
+   "om5p" | \
+   "om5p-an")
return 11
;;
"mr600v2")
return 15
;;
-   "mr900"|"mr900v2"|"mr1750")
+   "mr900" | \
+   "mr900v2" | \
+   "mr1750")
return 16
;;
esac
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] om-watchdog: Stop om-watchdog via procd before rebooting

2016-03-01 Thread Sven Eckelmann 
From: Sven Eckelmann 

It was noticed that the system can hang during the reboot before the kernel
actually triggers the system reset and before all processes are stopped. The
watchdog didn't automatically restart the system because the om-watchdog
process was still running and triggering the hardware watchdog.

Instead the system should stop the watchdog during the shutdown to get the
benefit of an hardware reset in case of an software related problem. This stop
can be done quite easily with procd because it keeps track of its started
processes.

Signed-off-by: Sven Eckelmann 
---
 package/kernel/om-watchdog/files/om-watchdog.init | 32 +--
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/package/kernel/om-watchdog/files/om-watchdog.init 
b/package/kernel/om-watchdog/files/om-watchdog.init
index c792968..47105f2 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -4,33 +4,49 @@
 #
 
 START=11
+STOP=11
 
-SERVICE_DAEMONIZE=1
+USE_PROCD=1
+NAME=om-watchdog
+PROG=/sbin/om-watchdog
 
-boot() {
+get_gpio() {
if [ -r /lib/ar71xx.sh ]; then
. /lib/ar71xx.sh
local board=$(ar71xx_board_name)
 
case "$board" in
"om2p"|"om2p-hs"|"om2p-hsv2")
-   service_start /sbin/om-watchdog 12
+   return 12
;;
"om2pv2"|"om2p-lc")
-   service_start /sbin/om-watchdog 26
+   return 26
;;
"om5p"|"om5p-an")
-   service_start /sbin/om-watchdog 11
+   return 11
;;
"mr600v2")
-   service_start /sbin/om-watchdog 15
+   return 15
;;
"mr900"|"mr900v2"|"mr1750")
-   service_start /sbin/om-watchdog 16
+   return 16
;;
esac
else
#we assume it is om1p in this case
-   service_start /sbin/om-watchdog 3
+   return 3
fi
+
+   return 255
+}
+
+start_service() {
+   get_gpio
+   gpio="$?"
+   [ "$gpio" != "255" ] || return
+
+   procd_open_instance
+   procd_set_param command "${PROG}" "${gpio}"
+   procd_set_param respawn
+   procd_close_instance
 }
-- 
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [musl] regex issue / asterisk / musl / sed

2016-03-01 Thread Bastian Bittorf 
* Szabolcs Nagy  [29.02.2016 20:35]:
> a possible fix is attached, the handling of ^ and $
> in BRE is suboptimal, but that will need a bigger
> refactoring.

thank you, fixes it for me on x86/UML and MIPS/ar71xx.

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

[OpenWrt-Devel] [PATCHv2] base-files: add function ucidef_set_interface_raw

2016-03-01 Thread micke . prag 
This function can be used to configure default configuration on 
interfaces other

than lan and wan, such as wlan or other custom interfaces.

Signed-off-by: Micke Prag 
---
 package/base-files/files/lib/functions/uci-defaults.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/package/base-files/files/lib/functions/uci-defaults.sh 
b/package/base-files/files/lib/functions/uci-defaults.sh

index 512e0ed..d36ead2 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -89,6 +89,12 @@ ucidef_set_interfaces_lan_wan() {
json_select ..
 }

+ucidef_set_interface_raw() {
+   json_select_object network
+   _ucidef_set_interface "$@"
+   json_select ..
+}
+
 _ucidef_add_switch_port() {
# inherited: $num $device $need_tag $role $index $prev_role
 	# inherited: $n_cpu $n_ports $n_vlan $cpu0 $cpu1 $cpu2 $cpu3 $cpu4 
$cpu5

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

[OpenWrt-Devel] [PATCH] target/mpc85xx: check for 'generic' subtarget for initramfs image file

2016-03-01 Thread Alexandru Ardelean 
From: Alexandru Ardelean 

Copy 'cuImage.tl-wdr4900-v1-initramfs' only for the 'generic' subtarget.
This is a follow-up to:
 
http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=b889fe55c1844aec2c03da28fecb03e958c21f18

We build our initramfs images more rarely, so it took a while
to catch this too.

Signed-off-by: Alexandru Ardelean 
---
 target/linux/mpc85xx/image/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/mpc85xx/image/Makefile 
b/target/linux/mpc85xx/image/Makefile
index 3c3f100..25a9b07 100644
--- a/target/linux/mpc85xx/image/Makefile
+++ b/target/linux/mpc85xx/image/Makefile
@@ -32,7 +32,9 @@ endef
 
 define Image/BuildKernel/Initramfs
cp $(KDIR)/zImage-initramfs $(BIN_DIR)/$(IMG_PREFIX)-initramfs-zImage
+ifeq ($(SUBTARGET),generic)
cp $(KDIR)/cuImage.tl-wdr4900-v1-initramfs 
$(BIN_DIR)/$(IMG_PREFIX)-tl-wdr4900-v1-initramfs.uImage
+endif
 endef
 
 define Image/Build/TPLINK
-- 
2.7.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] RT5350 board issues.

2016-03-01 Thread Frederic Konrad 
Hi everybody,
 
 I'm a openwrt newbie and I've some issues running OpenWRT on a RT5350 board.
 
 I tried "openwrt-15.05-ramips-rt305x-vmlinux.bin" which I transformed in
 uImage with:
 mkimage -A mips -O linux -T kernel -C none -a 0x8000 -e 0x8000 \
  -d openwrt-15.05-ramips-rt305x-vmlinux.bin uImage
 
 But I only get three lines loop when I put that on my target through uboot + 
tftp:
 
 [    0.00] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:34:21 CEST 2015
 [    0.00] SoC Type: Ralink RT5350 id:1 rev:3
 [    0.00] bootconsole [early0] enabled
 [    0.00] CPU0 revision is: 0001964c (MIPS 24KEc)
 [    0.00] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:34:21 CEST 2015
 [    0.00] SoC Type: Ralink RT5350 id:1 rev:3
 [    0.00] bootconsole [early0] enabled
 [    0.00] CPU0 revision is: 0001964c (MIPS 24KEc)
 [    0.00] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:34:21 CEST 2015
 [    0.00] SoC Type: Ralink RT5350 id:1 rev:3
 [    0.00] bootconsole [early0] enabled
 [    0.00] CPU0 revision is: 0001964c (MIPS 24KEc)
 [    0.00] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:34:21 CEST 2015
 [    0.00] SoC Type: Ralink RT5350 id:1 rev:3
 [    0.00] bootconsole [early0] enabled
 [    0.00] CPU0 revision is: 0001964c (MIPS 24KEc)
 [    0.00] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:34:21 CEST 2015
 [    0.00] SoC Type: Ralink RT5350 id:1 rev:3
 [    0.00] bootconsole [early0] enabled
 [    0.00] CPU0 revision is: 0001964c (MIPS 24KEc)
 [    0.00] Linux version 3.18.20 (buildbot@builder1) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r46450) ) #1 Fri Sep 4 19:34:21 CEST 2015
 [    0.00] SoC Type: Ralink RT5350 id:1 rev:3
 [    0.00] bootconsole [early0] enabled
 [    0.00] CPU0 revision is: 0001964c (MIPS 24KEc)
 
 I've the exact same result when I clone the git and compile the whole thing.
 
 Did I miss something?
Thanks,Fred
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] wwan: Add support for CDC (Huawei 'HiLink') Modems

2016-03-01 Thread John Crispin 


On 01/03/2016 12:14, Bruno Randolf wrote:
> On 03/01/2016 08:43 AM, John Crispin wrote:
>>
>>
>> On 26/02/2016 08:50, John Crispin wrote:
>>>
>>>
>>> On 25/02/2016 08:23, John Crispin wrote:


 On 24/02/2016 09:08, Bruno Randolf wrote:
> On 02/24/2016 06:11 AM, Matti Laakso wrote:
>>> The reason is that I want different types of Modems to work with the
>>> same interface configuration, using 'wwan'. E.g. it's configured like
>>> this (/etc/config/network):
>>>
>>> config interface 'umts'
>>> option proto wwan
>>> option apn internet.eplus.de
>>> option metric 4
>>>
>>> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported
>>> by "wwan" (which are hopefully more and more)... Doesn't that make
>>> sense? It would help the user who doesn't want to guess wether QMI works
>>> better than PPP for a specific modem and which serial port to use, 
>>> etc...
>>>
>>
>> That's a good goal, but I think it's confusing for the user when apn and
>> pin options don't work with HiLink modems but do work with all other
>> modems handled by wwan.
>
> Well, you can see it the other way round: they are not needed for HiLink
> modems and it will "just work"... :)
>
> bruno
>

 i have to say i agree most with bruno but i need to think about this a
 bit and i'll test it with the 2 hilinks i have here. i believe that
 having the wwan proto handle most of the options is desirable as it will
 not only unify the code path but also the config path which at the end
 will increase usability.

John

>>>
>>> Hi,
>>>
>>> this only works if the sim card has no pin set. correct ? i tried it and
>>> without logging into the webui and adding my pin/apn/ ... there it wont
>>> go online
>>>
>>> John
>>
>> i have spent ages thinking about this. the main problem is that the unit
>> wont go online unless we previously set the apn/pin, ... in the webui.
>> although having a unified wwan proto is great and we should have hilink
>> support in it, i fear that this will be rather ambiguous to users as
>> they set the pin in uci and then it wont get applied. so i have heavy
>> heartedly decided to NAK this. i wish i had more time so we could hack
>> up a tiny tool to set the webui setting from uci. although that is
>> really would be an ugly hack.
>>
>> sorry but i hope that the explanation makes sense.
> 
> Well, it makes sense only when you need to set APN and PIN. But this
> seems to depend on the Provider and SIM card settings.
> 
> I know two cases where this is not necessary: "eplus.de" and
> "vodafone.es" (PIN lock was disabled manually before in the vodafone.es
> case).
> 
> Anyhow, this is maybe not a generic enough situation to merit adding
> this to OpenWRT...
> 
> bruno

that is a SIM card feature. if you disable the pin none of the protos
need a PIN. i tested it on a eplus card and it did require an APN.
however there was a patch on the mailing list just now that posted the
mikrotik scripts. they should be easy to integrate. i know its an extra
todo but we really want to have a solution that will work for all SIM
cards and not just some depending on the provide. hope you agree

John



> ___
> 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] [PATCH 1/2] wwan: Add support for CDC (Huawei 'HiLink') Modems

2016-03-01 Thread Bruno Randolf 
On 03/01/2016 08:43 AM, John Crispin wrote:
> 
> 
> On 26/02/2016 08:50, John Crispin wrote:
>>
>>
>> On 25/02/2016 08:23, John Crispin wrote:
>>>
>>>
>>> On 24/02/2016 09:08, Bruno Randolf wrote:
 On 02/24/2016 06:11 AM, Matti Laakso wrote:
>> The reason is that I want different types of Modems to work with the
>> same interface configuration, using 'wwan'. E.g. it's configured like
>> this (/etc/config/network):
>>
>> config interface 'umts'
>> option proto wwan
>> option apn internet.eplus.de
>> option metric 4
>>
>> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported
>> by "wwan" (which are hopefully more and more)... Doesn't that make
>> sense? It would help the user who doesn't want to guess wether QMI works
>> better than PPP for a specific modem and which serial port to use, etc...
>>
>
> That's a good goal, but I think it's confusing for the user when apn and
> pin options don't work with HiLink modems but do work with all other
> modems handled by wwan.

 Well, you can see it the other way round: they are not needed for HiLink
 modems and it will "just work"... :)

 bruno

>>>
>>> i have to say i agree most with bruno but i need to think about this a
>>> bit and i'll test it with the 2 hilinks i have here. i believe that
>>> having the wwan proto handle most of the options is desirable as it will
>>> not only unify the code path but also the config path which at the end
>>> will increase usability.
>>>
>>> John
>>>
>>
>> Hi,
>>
>> this only works if the sim card has no pin set. correct ? i tried it and
>> without logging into the webui and adding my pin/apn/ ... there it wont
>> go online
>>
>>  John
> 
> i have spent ages thinking about this. the main problem is that the unit
> wont go online unless we previously set the apn/pin, ... in the webui.
> although having a unified wwan proto is great and we should have hilink
> support in it, i fear that this will be rather ambiguous to users as
> they set the pin in uci and then it wont get applied. so i have heavy
> heartedly decided to NAK this. i wish i had more time so we could hack
> up a tiny tool to set the webui setting from uci. although that is
> really would be an ugly hack.
> 
> sorry but i hope that the explanation makes sense.

Well, it makes sense only when you need to set APN and PIN. But this
seems to depend on the Provider and SIM card settings.

I know two cases where this is not necessary: "eplus.de" and
"vodafone.es" (PIN lock was disabled manually before in the vodafone.es
case).

Anyhow, this is maybe not a generic enough situation to merit adding
this to OpenWRT...

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

[OpenWrt-Devel] [PATCH] ar71xx: add support for the Telldus TellStick ZNet Lite

2016-03-01 Thread micke . prag 

Signed-off-by: Micke Prag 
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds |   5 +
 .../linux/ar71xx/base-files/etc/board.d/02_network |   5 +
 target/linux/ar71xx/base-files/etc/diag.sh |   3 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   6 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ar71xx/config-4.1 |   1 +
 target/linux/ar71xx/config-4.4 |   1 +
 .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  10 ++
 target/linux/ar71xx/files/arch/mips/ath79/Makefile |   1 +
 .../arch/mips/ath79/mach-tellstick-znet-lite.c | 129 
+

 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
 target/linux/ar71xx/generic/profiles/telldus.mk|  17 +++
 target/linux/ar71xx/image/Makefile |   9 ++
 13 files changed, 189 insertions(+)
 create mode 100644 
target/linux/ar71xx/files/arch/mips/ath79/mach-tellstick-znet-lite.c

 create mode 100644 target/linux/ar71xx/generic/profiles/telldus.mk

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds

index 151eac2..c787ed7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -407,6 +407,11 @@ smart-300)
ucidef_set_led_wlan "wlan" "WLAN" "nc-link:green:wlan" "phy0tpt"
;;

+tellstick-znet-lite)
+	ucidef_set_led_netdev "lan_act" "LANACT" "tellstick:green:lan" "eth0" 
"tx rx"
+	ucidef_set_led_netdev "lan_link" "LANLINK" "tellstick:orange:lan" 
"eth0" "link"

+   ;;
+
 tew-712br)
ucidef_set_led_netdev "wan" "WAN" "trendnet:green:wan" "eth1"
 	ucidef_set_led_switch "lan1" "LAN1" "trendnet:green:lan1" "switch0" 
"0x02"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network

index 799d98e..e88ef3a 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -192,6 +192,11 @@ el-m150)
"0:lan" "1:lan" "3@eth1" # XXX: confirm!
;;

+tellstick-znet-lite)
+   ucidef_set_interface_wan "eth0" "dhcp"
+   ucidef_set_interface_raw "wlan" "wlan0" "dhcp"
+   ;;
+
 tl-wdr4300|\
 tl-wr1041n-v2)
ucidef_add_switch "switch0" \
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh

index 1971b84..4078eab 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -263,6 +263,9 @@ get_status_led() {
qihoo-c301)
status_led="qihoo:green:status"
;;
+   tellstick-znet-lite)
+   status_led="tellstick:white:system"
+   ;;
tew-632brp)
status_led="tew-632brp:green:status"
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh

index 3203273..3a568d0 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -120,6 +120,9 @@ tplink_board_detect() {
"12"*)
model="MERCURY MAC1200R"
;;
+   "007260"*)
+   model="TellStick ZNet Lite"
+   ;;
"3C0001"*)
model="OOLITE"
;;
@@ -749,6 +752,9 @@ ar71xx_board_detect() {
"Smart Electronics Black Swift board"*)
name="bsb"
;;
+   *"Telldus TellStick ZNet Lite")
+   name="tellstick-znet-lite"
+   ;;
*TEW-632BRP)
name="tew-632brp"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh

index 8a70502..d410819 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -336,6 +336,7 @@ platform_check_image() {
onion-omega | \
oolite | \
smart-300 | \
+   tellstick-znet-lite | \
tl-mr10u | \
tl-mr11u | \
tl-mr12u | \
diff --git a/target/linux/ar71xx/config-4.1 
b/target/linux/ar71xx/config-4.1

index 0ccb278..0570749 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -123,6 +123,7 @@ CONFIG_ATH79_MACH_R6100=y
 # CONFIG_ATH79_MACH_RBSXTLITE is not set
 CONFIG_ATH79_MACH_RW2458N=y
 CONFIG_ATH79_MACH_SMART_300=y
+CONFIG_ATH79_MACH_TELLSTICK_ZNET_LITE=y
 CONFIG_ATH79_MACH_TEW_632BRP=y
 CONFIG_ATH79_MACH_TEW_673GRU=y
 CONFIG_ATH79_MACH_TEW_712BR=y
diff --git a/target/linux/ar71xx/config-4.4 
b/target/linux/ar71xx/config-4.4

index bef1863..c9ee122 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -126,6 +126,7 @@ CONFIG_ATH79_MACH_R6100=y
 # CONFIG_ATH79_MACH_RBSXTLITE is not set

Re: [OpenWrt-Devel] [PATCH 1/2] wwan: Add support for CDC (Huawei 'HiLink') Modems

2016-03-01 Thread John Crispin 


On 01/03/2016 10:34, Jakub Jančo wrote:
> On Tue, Mar 1, 2016 at 9:43 AM, John Crispin  wrote:
>> i have spent ages thinking about this. the main problem is that the unit
>> wont go online unless we previously set the apn/pin, ... in the webui.
>> although having a unified wwan proto is great and we should have hilink
>> support in it, i fear that this will be rather ambiguous to users as
>> they set the pin in uci and then it wont get applied. so i have heavy
>> heartedly decided to NAK this. i wish i had more time so we could hack
>> up a tiny tool to set the webui setting from uci. although that is
>> really would be an ugly hack.
> 
> By the way - mikrotik devices has PIN and APN settings for hilink too.
> Maybe there are some devices which support it - it didnt work for me,
> I had to set up things over webif.
> 
> I have done hack with wget to set PIN(huawei 3372h), but it is
> umaintained for now and I cant test it because we have device on
> "production" router.
> Problem can be a lot of APIs. And it needs to be able use cookies and
> post data.(If I remember I had to download full wget)
> 

reallly ugly stuff, but if anyone feels like merging this into the patch
that bruno posted then please do so.

John


> 
> If someone want play with it:
> In connect.post the PIN code is not variabled.
> --- config.sh
> #!/bin/sh
> gateway_ip="192.168.8.1"
> base_url="http://${gateway_ip};
> cookie_file="/tmp/cookie"
> connect_data="connect.post"
> connect_url="${base_url}/api/dialup/mobile-dataswitch"
> unlocksim_data="unlocksim.post"
> unlocksim_url="${base_url}/api/pin/operate"
> 
> token_url="${base_url}/html/home.html"
> request_token=$(wget -q -t 0 "$token_url" -O - --save-cookies
> "$cookie_file" --keep-session-cookies | grep csrf_token | head -n1 |
> cut -d'"' -f4)
> --
> --- connect.sh
> #!/bin/sh
> 
> . config.sh
> 
> [ -n "$request_token" ] || {
> echo No request token found
> exit 1
> }
> 
> wget -q -t 0 --load-cookies "$cookie_file"
> --header="__RequestVerificationToken: $request_token" \
>--post-file="$connect_data" "$connect_url" -O -
> --
> --- unlocksim.sh
> #!/bin/sh
> 
> . config.sh
> 
> [ -n "$request_token" ] || {
> echo No request token found
> exit 1
> }
> 
> wget -q -t 0 --load-cookies "$cookie_file"
> --header="__RequestVerificationToken: $request_token" \
> --post-file="$unlocksim_data" "$unlocksim_url" -O -
> --
> --- connect.post
>  encoding="UTF-8"?>0
> --
> --- connect.post
> 0
> --
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> S pozdravom Jakub Janco
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Fwd: [PATCH 1/2] wwan: Add support for CDC (Huawei 'HiLink') Modems

2016-03-01 Thread Jakub Jančo 
I corrected filenames.

If someone want play with it:
In unlocksim.post the PIN code is not variabled.
--- config.sh
#!/bin/sh
gateway_ip="192.168.8.1"
base_url="http://${gateway_ip};
cookie_file="/tmp/cookie"
connect_data="connect.post"
connect_url="${base_url}/api/dialup/mobile-dataswitch"
unlocksim_data="unlocksim.post"
unlocksim_url="${base_url}/api/pin/operate"

token_url="${base_url}/html/home.html"
request_token=$(wget -q -t 0 "$token_url" -O - --save-cookies
"$cookie_file" --keep-session-cookies | grep csrf_token | head -n1 |
cut -d'"' -f4)
--
--- connect.sh
#!/bin/sh

. config.sh

[ -n "$request_token" ] || {
echo No request token found
exit 1
}

wget -q -t 0 --load-cookies "$cookie_file"
--header="__RequestVerificationToken: $request_token" \
   --post-file="$connect_data" "$connect_url" -O -
--
--- unlocksim.sh
#!/bin/sh

. config.sh

[ -n "$request_token" ] || {
echo No request token found
exit 1
}

wget -q -t 0 --load-cookies "$cookie_file"
--header="__RequestVerificationToken: $request_token" \
--post-file="$unlocksim_data" "$unlocksim_url" -O -
--
--- connect.post
0
--
--- unlocksim.post
0
--

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

Re: [OpenWrt-Devel] [PATCH 1/2] wwan: Add support for CDC (Huawei 'HiLink') Modems

2016-03-01 Thread Jakub Jančo 
On Tue, Mar 1, 2016 at 9:43 AM, John Crispin  wrote:
> i have spent ages thinking about this. the main problem is that the unit
> wont go online unless we previously set the apn/pin, ... in the webui.
> although having a unified wwan proto is great and we should have hilink
> support in it, i fear that this will be rather ambiguous to users as
> they set the pin in uci and then it wont get applied. so i have heavy
> heartedly decided to NAK this. i wish i had more time so we could hack
> up a tiny tool to set the webui setting from uci. although that is
> really would be an ugly hack.

By the way - mikrotik devices has PIN and APN settings for hilink too.
Maybe there are some devices which support it - it didnt work for me,
I had to set up things over webif.

I have done hack with wget to set PIN(huawei 3372h), but it is
umaintained for now and I cant test it because we have device on
"production" router.
Problem can be a lot of APIs. And it needs to be able use cookies and
post data.(If I remember I had to download full wget)


If someone want play with it:
In connect.post the PIN code is not variabled.
--- config.sh
#!/bin/sh
gateway_ip="192.168.8.1"
base_url="http://${gateway_ip};
cookie_file="/tmp/cookie"
connect_data="connect.post"
connect_url="${base_url}/api/dialup/mobile-dataswitch"
unlocksim_data="unlocksim.post"
unlocksim_url="${base_url}/api/pin/operate"

token_url="${base_url}/html/home.html"
request_token=$(wget -q -t 0 "$token_url" -O - --save-cookies
"$cookie_file" --keep-session-cookies | grep csrf_token | head -n1 |
cut -d'"' -f4)
--
--- connect.sh
#!/bin/sh

. config.sh

[ -n "$request_token" ] || {
echo No request token found
exit 1
}

wget -q -t 0 --load-cookies "$cookie_file"
--header="__RequestVerificationToken: $request_token" \
   --post-file="$connect_data" "$connect_url" -O -
--
--- unlocksim.sh
#!/bin/sh

. config.sh

[ -n "$request_token" ] || {
echo No request token found
exit 1
}

wget -q -t 0 --load-cookies "$cookie_file"
--header="__RequestVerificationToken: $request_token" \
--post-file="$unlocksim_data" "$unlocksim_url" -O -
--
--- connect.post
0
--
--- connect.post
0
--










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

Re: [OpenWrt-Devel] [PATCH 1/3] IP Virtual Server - Load Balancer

2016-03-01 Thread John Crispin 
Hi,

we can merge this one into trunk if you resend it int he format i
requested in my original feedback. the other 2 patches/packages really
need to be merged in the packages feed on github.

John

On 23/02/2016 20:54, Mauro Mozzarelli wrote:
> All,
> 
> Please find enclosed the first of three patches to add IP Virtual Server 
> capability to OpenWRT
> This patch adds configuration for IP Virtual Server kernel modules
> This part does not have dependencies and it can be included without the 
> following 2 parts.
> 
> Mauro
> 
> Author: Mauro Mozzarelli 
> Date:   Tue Feb 23 19:18:24 2016 +
> 
> This ipvs package adds Linux IP Virtual Server capability to OpenWRT
> IPVS (IP Virtual Server) implements transport-layer load balancing inside 
> the Linux kernel, so called Layer-4 switching.
> IPVS running on a host acts as a load balancer at the front of a cluster of 
> real servers, it can direct requests for
> TCP/UDP based services to the real servers, and makes services of the real 
> servers to appear as a virtual service on a
> single IP address.
> 
> This patch enables configuration of the IP Virtual Server kernel modules
> 
> Signed-off-by: Mauro Mozzarelli 
> 
> diff --git a/package/kernel/linux/modules/netfilter.mk 
> b/package/kernel/linux/modules/netfilter.mk
> index a0a19b2..71bed3d 100644
> --- a/package/kernel/linux/modules/netfilter.mk
> +++ b/package/kernel/linux/modules/netfilter.mk
> @@ -270,6 +270,56 @@ define KernelPackage/ipt-ipset
>  endef
>  $(eval $(call KernelPackage,ipt-ipset))
> 
> +IPVS_MODULES:= \
> + ipvs/ip_vs \
> + ipvs/ip_vs_lc \
> + ipvs/ip_vs_wlc \
> + ipvs/ip_vs_rr \
> + ipvs/ip_vs_wrr \
> + ipvs/ip_vs_lblc \
> + ipvs/ip_vs_lblcr \
> + ipvs/ip_vs_dh \
> + ipvs/ip_vs_sh \
> + ipvs/ip_vs_fo \
> + ipvs/ip_vs_nq \
> + ipvs/ip_vs_sed
> +
> +define KernelPackage/ipvs
> +  SUBMENU:=Netfilter Extensions
> +  TITLE:=IP Virtual Server modules
> +  DEPENDS:=+kmod-lib-crc32c
> +  KCONFIG:= \
> + CONFIG_IP_VS \
> + CONFIG_IP_VS_IPV6=y \
> + CONFIG_IP_VS_DEBUG=n \
> + CONFIG_IP_VS_PROTO_TCP=y \
> + CONFIG_IP_VS_PROTO_UDP=y \
> + CONFIG_IP_VS_PROTO_AH_ESP=y \
> + CONFIG_IP_VS_PROTO_ESP=y \
> + CONFIG_IP_VS_PROTO_AH=y \
> + CONFIG_IP_VS_PROTO_SCTP=y \
> + CONFIG_IP_VS_TAB_BITS=12 \
> + CONFIG_IP_VS_RR \
> + CONFIG_IP_VS_WRR \
> + CONFIG_IP_VS_LC \
> + CONFIG_IP_VS_WLC \
> + CONFIG_IP_VS_FO \
> + CONFIG_IP_VS_OVF \
> + CONFIG_IP_VS_LBLC \
> + CONFIG_IP_VS_LBLCR \
> + CONFIG_IP_VS_DH \
> + CONFIG_IP_VS_SH \
> + CONFIG_IP_VS_SED \
> + CONFIG_IP_VS_NQ \
> + CONFIG_IP_VS_SH_TAB_BITS=8 \
> + CONFIG_IP_VS_NFCT=n \
> + CONFIG_NETFILTER_XT_MATCH_IPVS=n
> +
> +  FILES:=$(foreach mod,$(IPVS_MODULES),$(LINUX_DIR)/net/netfilter/$(mod).ko)
> +  #AUTOLOAD:=$(call AutoLoad,70,$(notdir $(IPVS_MODULES_LOAD)))
> +  $(call AddDepends/ipt,+kmod-ipt-conntrack)
> +endef
> +$(eval $(call KernelPackage,ipvs))
> 
>  define KernelPackage/ipt-nat
>TITLE:=Basic NAT targets
> ___
> 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] [PATCH 1/2] wwan: Add support for CDC (Huawei 'HiLink') Modems

2016-03-01 Thread John Crispin 


On 26/02/2016 08:50, John Crispin wrote:
> 
> 
> On 25/02/2016 08:23, John Crispin wrote:
>>
>>
>> On 24/02/2016 09:08, Bruno Randolf wrote:
>>> On 02/24/2016 06:11 AM, Matti Laakso wrote:
> The reason is that I want different types of Modems to work with the
> same interface configuration, using 'wwan'. E.g. it's configured like
> this (/etc/config/network):
>
> config interface 'umts'
> option proto wwan
> option apn internet.eplus.de
> option metric 4
>
> And it will work with PPP, QMI, MBIM, HiLink or whatever modem supported
> by "wwan" (which are hopefully more and more)... Doesn't that make
> sense? It would help the user who doesn't want to guess wether QMI works
> better than PPP for a specific modem and which serial port to use, etc...
>

 That's a good goal, but I think it's confusing for the user when apn and
 pin options don't work with HiLink modems but do work with all other
 modems handled by wwan.
>>>
>>> Well, you can see it the other way round: they are not needed for HiLink
>>> modems and it will "just work"... :)
>>>
>>> bruno
>>>
>>
>> i have to say i agree most with bruno but i need to think about this a
>> bit and i'll test it with the 2 hilinks i have here. i believe that
>> having the wwan proto handle most of the options is desirable as it will
>> not only unify the code path but also the config path which at the end
>> will increase usability.
>>
>>  John
>>
> 
> Hi,
> 
> this only works if the sim card has no pin set. correct ? i tried it and
> without logging into the webui and adding my pin/apn/ ... there it wont
> go online
> 
>   John

i have spent ages thinking about this. the main problem is that the unit
wont go online unless we previously set the apn/pin, ... in the webui.
although having a unified wwan proto is great and we should have hilink
support in it, i fear that this will be rather ambiguous to users as
they set the pin in uci and then it wont get applied. so i have heavy
heartedly decided to NAK this. i wish i had more time so we could hack
up a tiny tool to set the webui setting from uci. although that is
really would be an ugly hack.

sorry but i hope that the explanation makes sense.
John



> ___
> 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] [PATCH v2] ar71xx: Add OOLITE to the Gainstrong profile, removed standalone profile.

2016-03-01 Thread John Crispin 
nitpick inline

On 26/02/2016 20:24, Stijn Segers wrote:
> This patch moves the OOLITE profile code into the overarching Gainstrong
> profile and deletes the old single profile file.
> 
> Signed-off by: Stijn Segers 
> 
> ---
>  target/linux/ar71xx/generic/profiles/gainstrong.mk | 11 +++
>  target/linux/ar71xx/generic/profiles/oolite.mk | 18 --
>  2 files changed, 11 insertions(+), 18 deletions(-)
>  delete mode 100644 target/linux/ar71xx/generic/profiles/oolite.mk
> 
> diff --git a/target/linux/ar71xx/generic/profiles/gainstrong.mk 
> b/target/linux/ar71xx/generic/profiles/gainstrong.mk
> index a82529d..8f41539 100644
> --- a/target/linux/ar71xx/generic/profiles/gainstrong.mk
> +++ b/target/linux/ar71xx/generic/profiles/gainstrong.mk
> @@ -15,3 +15,14 @@ define Profile/MINIBOXV1/Description
>   Package set optimized for the Gainstrong MiniBox V1.0
>  endef
>  $(eval $(call Profile,MINIBOXV1))
> +
> +define Profile/OOLITE
> + NAME:=Gainstrong OOLITE
> + PACKAGES:=kmod-usb-core kmod-usb2  kmod-ledtrig-usbdev
  extra space here^

i have remove it manually while merging

John


> +endef
> +
> +
> +define Profile/OOLITE/Description
> + Package set optimized for the Gainstrong OOLITE.
> +endef
> +$(eval $(call Profile,OOLITE))
> diff --git a/target/linux/ar71xx/generic/profiles/oolite.mk 
> b/target/linux/ar71xx/generic/profiles/oolite.mk
> deleted file mode 100644
> index 448f08d..000
> --- a/target/linux/ar71xx/generic/profiles/oolite.mk
> +++ /dev/null
> @@ -1,18 +0,0 @@
> -#
> -# Copyright (C) 2009 OpenWrt.org
> -#
> -# This is free software, licensed under the GNU General Public License v2.
> -# See /LICENSE for more information.
> -#
> -
> -define Profile/OOLITE
> - NAME:=OOLITE
> - PACKAGES:=kmod-usb-core kmod-usb2  kmod-ledtrig-usbdev
> -endef
> -
> -
> -define Profile/OOLITE/Description
> - Package set optimized for the OOLITE.
> -endef
> -$(eval $(call Profile,OOLITE))
> -
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: EX2700: remove unused kernel modules

2016-03-01 Thread John Crispin 


On 26/02/2016 20:43, Joseph C. Lehner wrote:
> Remove the kmod-mt76 and kmod-rt2800-pci packages from the EX2700
> profile to free up around 100 KiB of space on the root filesystem.
> 
> This patch applies to both trunk and Chaos Calmer.
> 
> Signed-off-by: Joseph C. Lehner 
> 
> ---
> 
> diff --git a/target/linux/ramips/mt7620/profiles/netgear.mk
> b/target/linux/ramips/mt7620/profiles/netgear.mk
> index d1b073a..9631537 100644
> --- a/target/linux/ramips/mt7620/profiles/netgear.mk
> +++ b/target/linux/ramips/mt7620/profiles/netgear.mk
> @@ -7,7 +7,8 @@
> 
>  define Profile/EX2700
>   NAME:=Netgear EX2700
> - PACKAGES:=-kmod-usb-core -kmod-usb2 -kmod-usb-ohci -kmod-ledtrig-usbdev
> + PACKAGES:=-kmod-usb-core -kmod-usb2 -kmod-usb-ohci -kmod-ledtrig-usbdev 
> \
> + -kmod-mt76 -kmod-rt2800-pci

-kmod-rt2800-pci is wrong. i assume you are using the SDK driver but
that is not the case for everyone. please resend with this part removed.

John

>  endef
> 
>  define Profile/EX2700/Description
> ___
> 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] [PATCH] base-files: add function ucidef_set_interface_raw

2016-03-01 Thread John Crispin 


On 29/02/2016 17:25, micke.p...@telldus.se wrote:
> This function can be used to configure default configuration on
> interfaces other
> than lan and wan, such as wlan or other custom interfaces.
> 

Ok in general, but it would be nice if you also sent a patch that adds a
user for the function. could you do that ?

John



> Signed-off-by: Micke Prag 
> ---
>  package/base-files/files/lib/functions/uci-defaults.sh | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
> b/package/base-files/files/lib/functions/uci-defaults.sh
> index 512e0ed..d36ead2 100755
> --- a/package/base-files/files/lib/functions/uci-defaults.sh
> +++ b/package/base-files/files/lib/functions/uci-defaults.sh
> @@ -89,6 +89,12 @@ ucidef_set_interfaces_lan_wan() {
>  json_select ..
>  }
> 
> +ucidef_set_interface_raw() {
> +json_select_object network
> +_ucidef_set_interface "$@"
> +json_select ..
> +}
> +
>  _ucidef_add_switch_port() {
>  # inherited: $num $device $need_tag $role $index $prev_role
>  # inherited: $n_cpu $n_ports $n_vlan $cpu0 $cpu1 $cpu2 $cpu3 $cpu4
> $cpu5
> ___
> 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] [RFC]ramips: fix embedded switch init

2016-03-01 Thread John Crispin 


On 28/02/2016 04:59, serge wrote:
> Starting from AA when ramips support was added we get failsafe mode issue.
> Digging the problem I suggest:
> 
> 1. Change switch init: if vlan disabled set pvid 1 for all ports and add
> all ports
> into vlan0 with vid=1
> 2. Change init order in ethernet driver probe - init ESW after FE.
> 
> First step allow to set eth0 in predictable state after ethernet
> driver init'ed or at any time with simple:
> swconfig dev switch0 set reset 1
> 
> Second step is needed because some SOCs (rt5350,rt3352) reset FE and ESW
> together
> during ethernet probe but I think only for AA.
> 
> All these allow simplify ramips_set_preinit_iface() to set ifname=eth0
> only.
> Or add fallback to eth0 into preinit if both pi_ifname and ifname are
> undefined.
> In last case no need ramips_set_preinit_iface() at all.
> 
> Was tested for rt5350. Check for other SOCs is needed.

Hi,

can you test this on more SoCs please and also add the changes to
ramips_set_preinit_iface in a second patch please. if all works i'll
apply the same style fix to the gsw driver aswell

John

> 
> Signed-off-by: Serge Vasilugin 
> 
> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c
> +++ c/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c
> @@ -768,7 +768,7 @@ static int esw_apply_config(struct switc
>  doubletag |= x << i;
>  en_vlan   |= x << i;
>  untag |= x << i;
> -pvid   = 0;
> +pvid   = 1;
>  }
>  esw_set_pvid(esw, i, pvid);
>  if (i < RT305X_ESW_NUM_LEDS)
> @@ -795,7 +795,7 @@ static int esw_apply_config(struct switc
>   * isolated.
>   * NOTE: vlan 0 is special, no vlan tag is prepended
>   */
> -esw_set_vlan_id(esw, 0, 0);
> +esw_set_vlan_id(esw, 0, 1);
>  esw_set_vmsc(esw, 0, RT305X_ESW_PORTS_ALL);
>  }
> ___
> 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] [RFC 0/4] Add support for Raspberry Pi 3

2016-03-01 Thread John Crispin 


On 01/03/2016 07:04, Florian Fainelli wrote:
> On Feb 29, 2016 12:08 PM, "Álvaro Fernández Rojas"  > wrote:
>>
>> This adds untested support for Raspberry Pi 3.
>> I will be able to test it when I get my RPi 3 ;D.
> 
> Will give it a shot tomorrow morning, thanks for quickly sending the
> patches out.
> 

i am very opportunistic with these things, if it works let me know so i
can merge the patches.



>>
>> In the meantime if anyone already has a RPi 3 and wants to test it
> here's the image:
>>
> http://files.noltari.es/openwrt/rpi3/openwrt-brcm2708-bcm2710-rpi-3-ext4-sdcard.img
>>
> http://files.noltari.es/openwrt/rpi3/openwrt-brcm2708-bcm2710-rpi-3-ext4-sdcard.img.gz
>>
>> Álvaro Fernández Rojas (4):
>>   include: add Cortex-A53 CPU_TYPE
>>   brcm2708-gpu-fw: update to latest version
>>   brcm2708: update linux 4.4 patches to latest version
>>   brcm2708: add Raspberry Pi 3 support
>>
>>  include/target.mk  
> |   1 +
>>  package/kernel/brcm2708-gpu-fw/Makefile|   8 +-
>>  target/linux/brcm2708/Makefile |   8 +-
>>  target/linux/brcm2708/bcm2708/config-4.4   |   4 +-
>>  target/linux/brcm2708/bcm2709/config-4.4   |   4 +-
>>  target/linux/brcm2708/bcm2710/config-4.4   | 390 
>>  .../brcm2708/bcm2710/profiles/RaspberryPi3.mk  |  14 +
>>  target/linux/brcm2708/bcm2710/target.mk    
> |  12 +
>>  target/linux/brcm2708/image/Makefile   |  12 +-
>>  target/linux/brcm2708/modules.mk  
>  |  19 +
>>  ...0001-smsx95xx-fix-crimes-against-truesize.patch |   4 +-
>>  ...02-smsc95xx-Disable-turbo-mode-by-default.patch |   4 +-
>>  ...around-for-issue-where-dirty-page-count-g.patch |   4 +-
>>  .../0004-BCM2835_DT-Fix-I2S-register-map.patch |   4 +-
>>  ...-Prevent-spurious-interrupts-and-trap-the.patch |   4 +-
>>  .../0006-irqchip-bcm2835-Add-FIQ-support.patch |   4 +-
>>  ...-irqchip-irq-bcm2835-Add-2836-FIQ-support.patch |   4 +-
>>  ...erial-8250-Don-t-crash-when-nr_uarts-is-0.patch |   4 +-
>>  ...2835-Set-base-to-0-give-expected-gpio-num.patch |   4 +-
>>  ...2835-Fix-interrupt-handling-for-GPIOs-28-.patch |   4 +-
>>  ...2835-Only-request-the-interrupts-listed-i.patch |   4 +-
>>  ...cm2835-Support-pin-groups-other-than-7-11.patch |   4 +-
>>  ...RM-bcm2835-Set-Serial-number-and-Revision.patch |   4 +-
>>  ...-get-base-address-for-DMA-from-devicetree.patch |   4 +-
>>  ...-add-24bit-support-update-bclk_ratio-to-m.patch |   4 +-
>>  ...s-setup-clock-only-if-CPU-is-clock-master.patch |   4 +-
>>  ...835-i2s-Eliminate-debugfs-directory-error.patch |   4 +-
>>  .../0018-bcm2835-i2s-Register-PCM-device.patch |   4 +-
>>  ...i2s-Enable-MMAP-support-via-a-DT-property.patch |   4 +-
>>  ...0-dmaengine-bcm2835-Add-slave-dma-support.patch |   4 +-
>>  ...ine-bcm2835-set-residue_granularity-field.patch |   4 +-
>>  ...cm2835-Load-driver-early-and-support-lega.patch |   4 +-
>>  ...-dma-Fix-dreq-not-set-for-slave-transfers.patch |   4 +-
>>  ...-Limit-cyclic-transfers-on-lite-channels-.patch |   4 +-
>>  .../0025-bcm2835-Add-support-for-uart1.patch   |   4 +-
>>  ...irmware-bcm2835-Add-missing-property-tags.patch |   4 +-
>>  .../0027-Main-bcm2708-bcm2709-linux-port.patch |   4 +-
>>  ...-squash-include-ARCH_BCM2708-ARCH_BCM2709.patch |   4 +-
>>  .../patches-4.4/0029-Add-dwc_otg-driver.patch  |   4 +-
>>  .../0030-bcm2708-framebuffer-driver.patch  |   4 +-
>>  .../0031-dmaengine-Add-support-for-BCM2708.patch   |   4 +-
>>  ...-parameter-to-mmc-multi_io_quirk-callback.patch |   4 +-
>>  .../0033-MMC-added-alternative-MMC-driver.patch|   4 +-
>>  ...835-sdhost-driver-and-an-overlay-to-enabl.patch |   4 +-
>>  ...ma-Add-vc_cma-driver-to-enable-use-of-CMA.patch |   4 +-
>>  .../0036-bcm2708-alsa-sound-driver.patch   |   4 +-
>>  .../patches-4.4/0037-bcm2708-vchiq-driver.patch|   4 +-
>>  .../0038-vc_mem-Add-vc_mem-driver.patch|   4 +-
>>  ...deoCore-shared-memory-service-for-BCM2835.patch |   4 +-
>>  ...omem-device-for-rootless-user-GPIO-access.patch |   4 +-
>>  .../brcm2708/patches-4.4/0041-Add-SMI-driver.patch |   4 +-
>>  .../patches-4.4/0042-Add-SMI-NAND-driver.patch |   4 +-
>>  ...3-lirc-added-support-for-RaspberryPi-GPIO.patch |   4 +-
>>  .../patches-4.4/0044-Add-cpufreq-driver.patch  |   4 +-
>>  ...-thermal-driver-for-reporting-core-temper.patch |   4 +-
>>  .../0046-Add-Chris-Boot-s-i2c-driver.patch |   4 +-
>>  .../0047-char-broadcom-Add-vcio-module.patch   |   4 +-
>>  ...048-firmware-bcm2835-Support-ARCH_BCM270x.patch |   4 +-
>>  .../0049-bcm2835-add-v4l2-camera-device.patch  |   4 +-
>>  ...-mkknlimg-and-knlinfo-scripts-from-tools-.patch |   4 +-
>>  ...port-for-the-CONFIG_CMDLINE_EXTEND-option.patch |   4 +-
>>  ...0052-BCM2708-Add-core-Device-Tree-support.patch |   4 +-
>>