Re: [OpenWrt-Devel] r46816, remove unused crypt() algorithms -> switch to sha512?

Hi, Le 15 sept. 2015 01:40, "Felix Fietkau" a écrit : > > On 2015-09-15 00:22, Etienne Champetier wrote: > > Hi Felix, > > > > Maybe we should keep sha512 and switch to it? md5 is not best security > > practice these days. > I don't see the point. It's true that for file integrity purposes, md5 >

Re: [OpenWrt-Devel] OpenWrt /etc/hotplug.d/button/00-wps

Hi, I have written the following condition in /etc/hotplug.d/button/50-wps file if [ "$ACTION" = "pressed" -a "$BUTTON" = "lanwifi" ]; then echo "" > /dev/console echo "SWITCH TO RJ45" > /dev/console echo "255" > /sys/devices/platform/leds-gpio/leds/db120:green:status/brigh

[OpenWrt-Devel] OpenWrt /etc/hotplug.d/button/00-wps

Hi, I have to write some condition in /etc/hotplug.d/button/50-wps/ file I have to configure cat /etc/hotplug.d/button/00-wps file for following condition: if [ "$BUTTON" = "BTN_2" ] && [ "$ACTION" = "pressed" ]; then I have to check eth0.1 if link is up then have ON status led otherwise OFF. I

Re: [OpenWrt-Devel] [PATCH] [package] firewall: Adds support for IPv6 DNAT, SNAT, and REDIRECT

I've created a fork of the firewall3 git repo at git://nbd.name/firewall3.git on github repo, that contains this patch, for easier pulling: Please see: https://github.com/ecammit/firewall3 > On Aug 13, 2015, at 1:58 PM, Timothy Ace wrote: > > From: Timothy Ace > > Adds support for IPv6 DNAT,

Re: [OpenWrt-Devel] [PATCH] extra configuration options for OpenVPN in init script

On 28/08/2015 15:27, François Kooman wrote: > Hi Mirko, > > To accompany my patch to the OpenVPN configuration module for luci [0] > to support some extra fields here also the change to the OpenVPN init > script. > > It adds the following fields: > > tls_version_min > tls_version_max > key_dir

Re: [OpenWrt-Devel] [PATCH] AP121 target: fix board detection in ar71xx.sh

On 31/08/2015 12:58, Attila Lendvai wrote: > hi! > > resending this patch properly, including a signed-off entry. > > it would be nice if this could make its way into CC, because this > fixes a regression. > > the obsolete copy is this: https://patchwork.ozlabs.org/patch/508527/ > > Hi, th

Re: [OpenWrt-Devel] [PATCH] uci: add import call

Hi, SoB is missing and On 02/09/2015 02:14, Alexander Couzens wrote: > similiar to import from uci cli. > import removes all old configs and import the new config. > > example: > ubus call uci import \ > '{"config": "dhcp", "values": { "srv": { ".type": "host", ".name": "srv", > "mac":

Re: [OpenWrt-Devel] [PATCH procd v2 0/5] jail work

On 15/09/2015 00:11, Etienne Champetier wrote: > > Just some random stuffs: > > -new in kernel 4.3: ambient capabilities (great explanation in the commits) > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08 > http://git.kernel.or

Re: [OpenWrt-Devel] r46816, remove unused crypt() algorithms -> switch to sha512?

On 2015-09-15 00:22, Etienne Champetier wrote: > Hi Felix, > > Maybe we should keep sha512 and switch to it? md5 is not best security > practice these days. I don't see the point. It's true that for file integrity purposes, md5 is weaker than sha512, but for salted passwords it should not make muc

[OpenWrt-Devel] r46816, remove unused crypt() algorithms -> switch to sha512?

Hi Felix, Maybe we should keep sha512 and switch to it? md5 is not best security practice these days. I've checked, ubuntu 14.04 and fedora 22 both use sha512 in /etc/shadow I wonder if AF_ALG can be of any interest here (integrate needed algo by default into the kernel, then patch core software

Re: [OpenWrt-Devel] [PATCH procd v2 0/5] jail work

hi, 2015-08-27 13:38 GMT+02:00 John Crispin : > > > On 27/08/2015 13:25, Etienne Champetier wrote: > > > > > > 2015-08-27 12:18 GMT+02:00 John Crispin > >: > > > > > > > > On 26/08/2015 18:20, Etienne Champetier wrote: > > > > > > > > > 2015-08-26 15:48

[OpenWrt-Devel] [PATCH v2 4/7] target/mxs: adopt SD card generation to fixed U-Boot path

Signed-off-by: Michael Heimpold --- Changes in v2: - none target/linux/mxs/image/Makefile |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/mxs/image/Makefile b/target/linux/mxs/image/Makefile index 256d4e6..7e6a1a0 100644 --- a/target/linux/mxs/image/Makef

[OpenWrt-Devel] [PATCH v2 5/7] packages: uboot-mxs: fix I2SE Duckbill variant

The current patch to add Duckbill support is wrong and does not even compile. So replace this patch with a working one. Signed-off-by: Michael Heimpold --- Changes in v2: - none .../uboot-mxs/patches/001-add-i2se-duckbill.patch | 82 +++- 1 file changed, 46 insertions(+), 36

[OpenWrt-Devel] [PATCH v2 7/7] target: mxs: re-work SD card image generation

- Duckbill uses a different partitioning approach than standard FSL and Olimex - use new sdimage to integrate U-Boot into the SD card images Signed-off-by: Michael Heimpold --- Changes in v2: - new patch target/linux/mxs/image/Config.in |9 -- target/linux/mxs/image/Mak

[OpenWrt-Devel] [PATCH v2 3/7] packages: uboot-mxs: bless UBOOT_IMAGE with a meaning, otherwise we could drop this C&P left-over

Signed-off-by: Michael Heimpold --- Changes in v2: - none package/boot/uboot-mxs/Makefile |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile index eee73d2..373b8d8 100644 --- a/package/boot/uboot-mxs/Mak

[OpenWrt-Devel] [PATCH v2 1/7] packages: uboot-mxs: place binaries in the designated path

Signed-off-by: Michael Heimpold --- Changes in v2: - none package/boot/uboot-mxs/Makefile |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile index 1686f60..a6a137c 100644 --- a/package/boot/uboot-mxs/Mak

[OpenWrt-Devel] [PATCH v2 6/7] tools: add sdimage (for mxs target)

This tool is used for SD card generation on Freescale i.MX23/i.MX28 platforms. These CPU's ROM need a tiny header of front of a boot stream. Signed-off-by: Michael Heimpold --- Changes in v2: - new patch tools/Makefile |2 +- tools/sdimage/Makefile | 37 ++

[OpenWrt-Devel] [PATCH v2 2/7] packages: uboot-mxs: do no modify the U-Boot image, copy as-is

Signed-off-by: Michael Heimpold --- Changes in v2: - none package/boot/uboot-mxs/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/boot/uboot-mxs/Makefile b/package/boot/uboot-mxs/Makefile index a6a137c..eee73d2 100644 --- a/package/boot/uboot-mxs/Makefile

[OpenWrt-Devel] [PATCH v2 0/7] target: mxs: various fixes

This patch series is to bring OpenWrt's Duckbill support back in shape: - U-Boot build is fixed - SD card generation is adopted for Duckbill images I've tested my changes with I2SE Duckbill and Olimex OLinuXino Maxi board, however, I've no Micro/Mini at hand. This series obsoletes my series "pack

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

Hi, On 09/09/2015 16:56, Weijie Gao wrote: > Signed-off-by: Weijie Gao this line should be the last line and not the first, i manually fixed this during the merge John > > This patch adds support for TP-LINK TL-WDR3320 v2. > > This router uses a chinese version 2 firmware header,. >

Re: [OpenWrt-Devel] [PATCH] base-files: assign proper GPIO pin for Ubiquiti Nanostation models

you used the wrong prefix, i fixed it manually, please double check it next time John On 13/09/2015 00:33, Lars Kruse wrote: > The GPIO pins for "POE passthrough" of Ubiquiti Nanostation models are the > following: > * Ubiquiti Nanostation M XM: Pin 8 > * Ubiquiti Nanostation M XW: Pin 2

Re: [OpenWrt-Devel] [PATCH] [LANTIQ] ARV7519RW22 dts fix

On 02/09/2015 16:34, José Vázquez Fernández wrote: > From a9d8a4d04c5564abb0440a3b67dd21e8645e2c43 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Jos=C3=A9=20V=C3=A1zquez=20Fern=C3=A1ndez?= > > Date: Tue, 1 Sep 2015 19:30:26 +0200 > Subject: [OpenWrt-Devel] [PATCH] [LANTIQ] ARV7519RW22 dts fix > >

Re: [OpenWrt-Devel] i2c device not in /dev

On 14/09/2015 20:09, Daniel Golle wrote: > On Mon, Sep 14, 2015 at 07:47:08PM +0200, John Crispin wrote: >> On 14/09/2015 19:28, Baptiste Clenet wrote: >>> Hi, >>> >>> I'm using a MT7628 chip and I try to implement an I2C device which >>> will use i2c-ralink adapter. I registered my i2c device wi

Re: [OpenWrt-Devel] [PATCH] build: fixes feeds with Makefile in root directory (#20392)

I sent this (my first ever) patch in a few weeks ago, has anyone had time to review it? If I did something wrong, please let me know. Thanks. *[image: cid:image001.png@01CFCC2A.38674B20]* * Ryan Lindeman*, Software Engineer 11778 South Election Road, Suite 260 *|* Draper, UT 84020 *|* USA

Re: [OpenWrt-Devel] i2c device not in /dev

On Mon, Sep 14, 2015 at 07:47:08PM +0200, John Crispin wrote: > On 14/09/2015 19:28, Baptiste Clenet wrote: > > Hi, > > > > I'm using a MT7628 chip and I try to implement an I2C device which > > will use i2c-ralink adapter. I registered my i2c device with > > module_i2c_driver(i2c_device_driver);

Re: [OpenWrt-Devel] i2c device not in /dev

On 14/09/2015 19:28, Baptiste Clenet wrote: > Hi, > > I'm using a MT7628 chip and I try to implement an I2C device which > will use i2c-ralink adapter. I registered my i2c device with > module_i2c_driver(i2c_device_driver); > > I can see it on my bus: > ./sys/bus/i2c/drivers/i2c_device_driver > B

Re: [OpenWrt-Devel] Target profiles: making "make" build every profile

On 2015-09-14 12:06, Jonas Gorski wrote: > Hi, > > On Mon, Sep 14, 2015 at 11:30 AM, Rafał Miłecki wrote: >> Quick summary: >> Subtargets - used for building modified kernels >> Profiles - used for including specific software >> >> There are two ways of using profiles: >> >> 1) Changing some soft

[OpenWrt-Devel] [RFC] ralink: Allow to receive vlan over untag ports on MT7530

The MT7530 switch driver with enable_vlan set will automatically set all ports to the user port mode. The hardware will remove the incoming vlan tag on these ports and use it for its internal vlan. This is usually not wanted and makes it impossible to communicate via vlan over the switch in both di

[OpenWrt-Devel] i2c device not in /dev

Hi, I'm using a MT7628 chip and I try to implement an I2C device which will use i2c-ralink adapter. I registered my i2c device with module_i2c_driver(i2c_device_driver); I can see it on my bus: ./sys/bus/i2c/drivers/i2c_device_driver But it doesn't appear in /dev. What am I doing wrong? Regards

Re: [OpenWrt-Devel] Chaos Calmer 15.05

On 09/11/2015 09:56 AM, Rafał Miłecki wrote: > On 11 September 2015 at 10:54, Steven Barth wrote: >> The OpenWrt developers are proud to announce the final release of OpenWrt >> Chaos Calmer. > > Before someone asks, it's > r46767 > 483dac821788b457d349233e770329186a0aa860 > ramips: fix devicetr

Re: [OpenWrt-Devel] [PATCH] Complete the trunk rename from Chaos Calmer to Designated Driver

On Mon, Sep 14, 2015 at 12:36 AM, Karl Palsson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hartmut Knaack wrote: >> Hannu Nyman schrieb am 13.09.2015 um 19:51: >> > Sorry, but what is the problem? >> >> Most importantly: laziness. In my case, I just keep hitting the next >> email

Re: [OpenWrt-Devel] QinQ on MT7530/MT7621

On Tuesday 08 September 2015 15:01:09 Sven Eckelmann wrote: > Hi, > > I was testing QinQ/stacked vlan/double vlan/doubletag on MT7621 and > noticed that it didn't work. I see packets correctly send with the > the stacked VLAN tag but the replies are never received by eth0. [...] Just some notes:

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

On 2015-09-13 10:21, MauritsVB wrote: > At the moment the OpenWRT www login screen provides *very* detailed version > information before anyone has even entered a password. It displays not just > “15.05” or “Chaos Calmer” but even the exact git version on the banner. > > While it’s not advised t

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

On 2015-09-13 15:30, Daniel Dickinson wrote: > Oh and 1 has the benefit of actually securing the device against wan access > to LuCI even in the case of firewall not blocking such access, whereas the > robots.txt and hiding banner are classic 'security through obscurity' which > is the > security p

Re: [OpenWrt-Devel] Chaos Calmer 15.05

On 11 September 2015 at 11:29, John Crispin wrote: > On 11/09/2015 11:27, Daniel Golle wrote: >> However, it seems like images for some boards got missing at least on >> lantiq and oxnas. > > ah indeed, i missed the IB images. will add them during the weekend They are available now, thanks John!

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

I agree that adding a robots.txt with User-agent: * Disallow: / would be worth it, considering it’s a small effort and minimal space penalty. It doesn’t stop Banner Grabbing tools but it does stop casual indexing by benign search tools. Of course, removing the version banner or adding a robots.t

[OpenWrt-Devel] Questions about "binutils: add binutils 2.25.1"

Hi Hauke, I noticed your change made in "toolchain/binutils" recently: ->8- http://git.openwrt.org/?p=openwrt.git;a=commit;h=fece50d94033c1dcfc3f290acbd428f9125c30aa binutils: add binutils 2.25.1 This adds binutils 2.25.1 as an option to OpenWrt. Signed-off-by: Hauke

Re: [OpenWrt-Devel] [PATCH 0/3] Add support of ARC architecture

Hi John, On Mon, 2015-09-14 at 13:41 +0200, John Crispin wrote: > > On 14/09/2015 13:35, Alexey Brodkin wrote: > > Hi Felix, > > > > On Fri, 2015-09-11 at 15:09 +0200, Felix Fietkau wrote: > > > On 2015-08-27 13:03, Alexey Brodkin wrote: > > > > This patch series adds support for the Synopsys De

Re: [OpenWrt-Devel] [PATCH 0/3] Add support of ARC architecture

On 14/09/2015 13:35, Alexey Brodkin wrote: > Hi Felix, > > On Fri, 2015-09-11 at 15:09 +0200, Felix Fietkau wrote: >> On 2015-08-27 13:03, Alexey Brodkin wrote: >>> This patch series adds support for the Synopsys DesignWare ARC architecture. >>> >>> DesignWare ARC700 is family of 32-bit CPUs dev

Re: [OpenWrt-Devel] [PATCH 0/3] Add support of ARC architecture

Hi Felix, On Fri, 2015-09-11 at 15:09 +0200, Felix Fietkau wrote: > On 2015-08-27 13:03, Alexey Brodkin wrote: > > This patch series adds support for the Synopsys DesignWare ARC architecture. > > > > DesignWare ARC700 is family of 32-bit CPUs developed by Synopsys, Inc. > > > > Since version 3.9

[OpenWrt-Devel] [PATCH v2 netifd] interface-ip: Fix broadcast address when using /31 or /32 IPv4 addressing

From: Baptiste Jonglez A /31-addressed interface requires a broadcast address of 255.255.255.255, because there is no room for a proper broadcast address. Without this, any packet destinated to the other end of the link is sent as broadcast, which is incorrect. For consistency with the Linux ke

Re: [OpenWrt-Devel] Target profiles: making "make" build every profile

Hi, On Mon, Sep 14, 2015 at 11:30 AM, Rafał Miłecki wrote: > Quick summary: > Subtargets - used for building modified kernels > Profiles - used for including specific software > > There are two ways of using profiles: > > 1) Changing some software for all devices > Used when profile is used for a

[OpenWrt-Devel] [PATCH v2][netifd] Initialize wireless interface attributes in proper function

Initialize wireless interface attributes in proper function. Currently multicast to unicast feature may be configured for incorrect wireless interface in case of reconfiguration. Test case: Initial wireless configuration: config wifi-iface option mode ap option disabled 1 config wifi-ifac

[OpenWrt-Devel] Target profiles: making "make" build every profile

Quick summary: Subtargets - used for building modified kernels Profiles - used for including specific software There are two ways of using profiles: 1) Changing some software for all devices Used when profile is used for all devices (no filtering, no per device profiles). This is used e.g. by brc

[OpenWrt-Devel] [PATCH][netifd] Initialize wireless interface attributes in proper function

Initialize wireless interface attributes in proper function. Currently multicast to unicast feature may be configured for incorrect wireless interface in case of reconfiguration. Test case: Initial wireless configuration: config wifi-iface option mode ap option disabled 1 config wifi-ifac

[OpenWrt-Devel] [PATCH netifd] interface-ip: Fix broadcast address when using /31 IPv4 addressing

A /31-addressed interface requires a 255.255.255.255 broadcast, because there is no room for a proper broadcast address. Without this, any packet destinated to the other end of the link is sent as broadcast, which is incorrect. Signed-off-by: Baptiste Jonglez --- interface-ip.c | 15 ++-

[OpenWrt-Devel] [PATCH] musl: fix build on sh3

musl fails to build when compiled with gcc on sh3 (GCC target/#67260). Work it around. Signed-off-by: Zoltan HERPAI --- toolchain/musl/common.mk |5 + 1 file changed, 5 insertions(+) diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk index 82c1543..ba467fb 100644 --- a/to

Re: [OpenWrt-Devel] Chaos Calmer 15.05

First of all, congratulations to all of you for the great effort. I just want to post a simple questionI have noticed that the the LUCI control panel still returns a null MAC Address for both the wired and wireless network cards. If I remember well, the developers are well aware of this issue w

Re: [OpenWrt-Devel] Question about openwrt release revision

On 14/09/2015 09:34, pupie wrote: > Hello everyone, > I am so glad that openwrt 15.05 has been release. > > I noticed that since AA release, openwrt team neither tag the source > tree in subversion/git after an official release nor provide the > revision/commit sha-1 along with release note. > I

[OpenWrt-Devel] Question about openwrt release revision

Hello everyone, I am so glad that openwrt 15.05 has been release. I noticed that since AA release, openwrt team neither tag the source tree in subversion/git after an official release nor provide the revision/commit sha-1 along with release note. I just want to know where can I get this info and w

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

Hi, Le 14 sept. 2015 06:36, "Daniel Dickinson" a écrit : > > On 2015-09-14 12:30 AM, Daniel Dickinson wrote: >> >> On 2015-09-13 11:39 PM, Florian Fainelli wrote: >>> >>> On Sep 13, 2015 2:00 PM, "Etienne Champetier" >>> mailto:champetier.etie...@gmail.com>> >>> wrote: >>> > >>> > Hi Daniel, >>